글 작성자: _rian

클라우드 보안은 공유 책임

조직에서는 보안 전문가를 고용 및 유지하고 여러 보안 도구를 사용하고 위협의 규모 및 복잡성에 따라 보안 수준을 맞추는 등 데이터 센터 보호와 관련된 여러가지 문제를 겪고있다.

컴퓨팅 환경이 클라우드로 전환이 되면서 보안의 책임 소재도 바뀌는데, 이제 운영 환경의 보안은 클라우드 공급자과 고객 모두의 문제가 되었다.

IaaS를 사용하면 가장 낮은 계층의 서비스를 활용하고 Azure에 VM(가상머신) 및 가상 네트워크를 만들도록 요청한다. 이 수준에서는 여전히 운영 체제와 소프트웨어를 패치 및 보호하고 네트워크를 안전하게 유지하는 일을 해야하지만, 네트워크의 물리적인 부분을 보호하는 것과 관련하여 문제를 아웃소싱하는 보안상의 이점을 얻을 수 있다.

PaaS는 아웃소싱하는 범위가 더 넓어지는데, 이 수준에서 Azure는 운영체제 및 데이터베이스 관리시스템과 같은 대부분의 기본 소프트웨어를 관리한다. 모든 소프트웨어는 최신 보안 패치로 업데이트되며, 액세스 제어를 위해 Azure Active Directory와 통합될 수 있다. 사용자 환경에 맞게 전체 인프라와 서브넷을 직접 빌드하는 대신, Azure Portal 내에서 그냥 클릭하거나 자동화된 스크립트를 실행하여 복잡한 보안 시스템을 필요에따라 이동하고 크기를 조정할 수 있다.

SaaS를 사용하면 거의 모든 요소를 아웃소싱할 수 있다. 

모든 클라우드 배포 유형에서 사용자는 고유의 데이터와 ID를 소유한다. 사용자는 데이터와 ID, 온프레미스 리소스 및 제어하는 클라우드 구성요소를 보호할 책임이 있다.

배포 유형과 관계 없이 아래에 대한 책임은 항상 사용자에게 있다.

  • 데이터
  • 엔드포인트
  • 계정
  • 액세스 관리

 

보안에 대한 계층화된 접근방법

심층 방어는 정보에 무단으로 액세스하려는 공격의 진행 속도를 늦추는 일련의 메커니즘을 사용하는 전략이다. 각 레이어가 보호를 제공하므로 한 레이어에서 보안 위반이 발생하더라도 후속 레이어가 이미 적용되어 추가 노출을 방지한다. 액세스 권한이 없는 개인으로부터 정보를 보호하고 도난을 방지하는데 사용한다.

심층방어는 일련의 동심원으로 시각화할 수 있으며, 그 중심에 데이터를 배치하여 보호한다. 각 원은 데이터 주변에 추가 보안 레이어를 추가한다. 이 방법을 사용하면 단일 보호 레이어에 의존하지 않고 공격 속도를 늦출 수 있으며, 자동 혹은 수동으로 경고 원격 분석을 제공할 수 있다. 각 레이어를 살펴보도록 하자.

(1) 데이터

대부분의 경우 공격자는 다음과 같은 데이터를 목표로 한다.

  • 데이터베이스에 저장된 데이터
  • 가상 머신 내부의 디스크에 저장된 데이터
  • Office 365와 같은 SaaS 어플리케이션에 저장된 데이터
  • 클라우드 스토리지에 저장된 데이터

데이터를 저장하고 액세스를 제어하는 사용자는 데이터를 적절하게 보호할 책임이 있다. 종종 데이터의 기밀성, 무결성 및 가용성을 보장하기 위한 제어 및 프로세스를 적용할 것을 지시하는 규제 요구 사항이 있다.

(2) 어플리케이션

  • 어플리케이션이 안전하고 취약하지 않은지 확인
  • 중요한 어플리케이션 비밀을 안전한 저장 매체에 저장
  • 보안 항목을 모든 어플리케이션 개발의 디자인 요구사항에 포함

(3) 컴퓨팅

  • 가상 머신에 대한 액세스를 보호
  • 엔드포인트 보호를 구현하고 시스템을 패치하고 최신 상태로 유지

맬웨어, 패치되지 않은 시스테과 부적절한 보안 시스템은 사용자의 환경을 공격에 노출시킨다.

(4) 네트워킹

  • 리소스간의 통신을 제한
  • 기본적으로 거부
  • 적절한 경우 인바운드 인터넷 액세스를 금지하고 아웃바운드를 제한
  • 온프레미스 네트워크에 대한 보안 연결을 구현

여기서 핵심은 모든 리소스에 대한 네트워크 연결을 제한해서 필요한 것만 허용하는 것이다. 이 통신을 제한하여 네트워크 전체에서 수평 이동의 위험을 줄일 수 있다.

(5) 경계

  • DDoS(분산 서비스 거부) 보호 기능을 사용하여 최종 사용자에게 서비스 거부가 발생하기 전에 대규모 공격을 필터링한다.
  • 경계 방화벽을 사용하여 네트워크에 대한 악의적인 공격을 식별하고 경고한다.

네트워크 경계에서, 리소스에 대한 네트워크 기반 공격을 방어한다. 이러한 공격을 파악하여 영향을 제거하고 발생한 공격을 경고하는 것이 네트워크를 안전하게 유지하는 중요한 방법이다.

(6) ID 및 액세스

ID를 안전하게 보호하고, 필요한 것에만 액세스 권한을 부여하고 변경 내용을 기록하는지 확인

  • 인프라에 대한 접근 및 제어 변경을 통제
  • Single Sign-On 및 다단계 인증을 사용
  • 이벤트 및 변경 내용을 감사

(7) 물리적 보안

자산 액세스에 대한 물리적 보호 수단을 제공해 다른 레이어가 무시되지 않고 손실 또는 도난이 적절하게 처리되도록 한다. 이 보호수단은 다른 레이어가 무시되지 않고 손실 또는 도난이 적절하게 처리되도록 한다.

Azure Security Center에서 팁 얻기

Azure 기반 솔루션의 보안 검사를 시작하기에 적합한 위치는 Azure Security Center다. Security Center는 Azure와 온프레미스의 모든 서비스에 대한 위협 보호를 제공하는 모니터링 서비스다. 

 

  • 구성, 리소스 및 네트워크를 기반으로 보안 추천을 제공합니다.
  • 온-프레미스 및 클라우드 워크로드의 보안 설정을 모니터링하면서 새 서비스가 온라인으로 전환되면 필요한 보안을 자동으로 적용합니다.
  • 모든 서비스를 지속적으로 모니터링하면서 자동 보안 평가를 수행하여 잠재적 취약점이 악용되기 전에 미리 식별합니다.
  • 기계 학습을 사용하여 맬웨어를 탐지하고 가상 머신과 서비스에 설치되지 않도록 차단합니다. 또한 유효성을 검사한 앱만 실행할 수 있도록 허용되는 애플리케이션 목록을 정의할 수 있습니다.
  • 잠재적 인바운드 공격을 분석 및 식별하고, 발생했을지도 모르는 위협 및 게시물 보안 위반 활동을 조사합니다.
  • 포트에 대한 Just-In-Time 액세스 제어를 제공하고, 필요한 트래픽만 네트워크에서 허용하여 공격 노출 영역을 줄입니다.

사용 가능한 계층

Azure Security Center는 두 계층으로 제공된다.

  1. 체험 : Azure 구독의 일부로 제공되는 이 계층은 Azure 리소스의 평가 및 추천으로 제한된다.
  2. 표준 : 이 계층은 연속 모니터링, 위협 탐지, 포트에 대한 Just-In-Time 액세스 제어를 포함하여 완전한 보안 관련 서비스 제품군을 제공한다. 

Azure Security Center 서비스의 전체 제품군에 액세스하려면 표준 계층 구독으로 업그레이드 해야한다. 

사용 시나리오

Security Center를 워크플로와 통합하여 여러가지 방법으로 사용할 수 있다.

1. 사고 대응에 Security Center 사용

탐지, 평가 및 진단 단계에서 Security Center를 사용할 수 있다.

  • 탐지 : 이벤트 조사의 첫 번째 표시를 검토. 예를들어 Security Center 대시보드를 사용하여 높은 우선 순위 보안 경고가 발생한 초기 검증을 검토할 수 있다.
  • 평가 : 초기 평가를 수행하여 의심스러운 작업에 대한 자세한 정보를 가져온다. 예를들어 보안 경고에 대한 자세한 정보를 가져온다.
  • 진단 : 기술조사를 수행하고 포함, 완화 및 해결 방법 전략을 식별한다. 예를들어 해당 특정 보안 경고에서 Security Center에 설명한 수정 단계를 따른다.

2. Security Center 추천을 사용하여 보안을 강화

보안 정책을 구성한 다음, Azure Security Center에서 제공한 추천을 구현하여 중요한 보안 이벤트의 가능성을 줄일 수 있다.

  • 보안 정책은 지정된 구독 또는 리소스 그룹 내에서 리소스에 대해 권장되는 컨트롤 세트를 정의한다. 회사의 보안 요구에 따라 정책을 정의.
  • 보안 센터에서는 Azure 리소스의 보안 상태를 분석한다. Security Center는 잠재적인 보안 취약성을 식별하면 보안 정책에서 설정된 컨트롤에 따라 권장 사항을 만든다. 추천은 필요한 보안 컨트롤을 구성하는 과정을 안내한다. 

ID 및 액세스

회사 데이터를 보호하는 데 주로 네트워크 경계와 해당 방화벽 및 물리적 액세스 제어를 활용했다. 그러나 네트워크 경계는 BYOD(Bring Your Own Device), 모바일 앱 및 클라우드 어플리케이션이 폭발적으로 증가함에 따라 차츰 허점이 드러나게 되었다. 

인증 및 권한 부여

ID 및 액세스 제어에 대해 이야기 할 때 이해해야 하는 두 가지 기본 개념은 인증과 권한 부여다. 인증과 권한 ㅜ여는 발생하는 모든 것의 기반이 되며 ID 및 액세스 프로세스를 순차적으로 이루어진다.

  • 인증 : 리소스에 액세스하려는 사람 또는 서비스의 ID를 설정하는 프로세스. 당사자에게 합법적인 자격 증명을 요구하는 행동이 포함되며, ID 및 액세스 제어에 사용할 보안 주체를 만들기 위한 기반을 제공한다.
  • 권한 부여 : 인증된 사용자 또는 서비스가 갖는 액세스 수준을 설정하는 프로세스. 액세스할 수 있는 데이터와 해당 데이터로 할 수 있는 작업을 지정한다.

Azure는 Azure AD(Azure Active Directory)를 통해 인증 및 권한 부여를 관리하는 서비스를 제공한다.

Azure Active Directory란?

Azure AD는 클라우드 기반 ID 서비스로, 기본적으로 제공되는 지원이며 기존 온프레미스 Active Directory와 동기화할 수 있고 독립 실행형으로 사용할수도 있다. 즉, 온프레미스든 클라우드든 모바일이든 관계 없이 모든 어플리케이션이 동일한 자격 증명을 공유할 수 있다. 관리자와 개발자는 중앙 집중식 규칙과 Azure AD에서 구성한 정책을 사용하여 내부 및 외부 데이터와 어플리케이션에 대한 액세스를 제어할 수 있다.

Azure AD에서는 아래와 같은 서비스를 제공하고 있다.

  • 인증 : 여기에는 어플리케이션 및 리소스에 액세스하는 ID를 확인하는 것과 셀프 서비스 암호 재설정, MFA(다단계 인증), 사용자 지정 금지 암호 목록, 스마트 잠금 서비스 등의 기능을 제공하는 것이 포함된다.
  • SSO(Single Sign On) : SSO를 사용하면 사용자가 한 가지 ID와 한 가지 암호만 기억하면 여러 어플리케이션에 액세스할 수 있다. 한 ID가 한 사용자에게 연결되므로 보안 모델이 간소화된다. 액세스 수정이 해당 ID에 연결되어 있으므로 사용자 역할이 변경되거나 사용자가 조직을 떠날 때 계정을 변경하거나 비활성화하는 과정이 대폭 축소된다.
  • 어플리케이션 관리 : Azure AD 어플리케이션 프록시, SSO 내 앱 포털 및 SaaS 앱을 사용하여 클라우드 및 온프레미스 앱을 관리할 수 있다.
  • B2B ID 서비스 : 회사 데이터에 대한 제어를 유지하면서도 게스트 사용자 및 외부 파트너를 관리한다.
  • B2C ID 서비스 : 사용자가 앱을 서비스에 사용할 때 프로필을 가입, 로그인 및 관리하는 방법을 사용자 지정하고 제어한다.
  • 디바이스 관리 : 클라우드 또는 온프레미스 디바이스가 회사 데이터에 액세스하는 방법을 관리한다.

 

Signle Sign On

사용자가 관리할 ID가 많을수록 자격 증명 관련 보안 사건이 발생할 위험이 높다. 더 많은 ID는 더 많은 암호를 기억하고 변경해야한다는 뜻이다. 

SSO를 사용하면 사용자가 ID 하나와 암호 하나만 기억하고 있으면 된다. 어플리케이션에 대한 액세스 권한이 사용자와 연결된 ID에 부여되므로 보안 모델이 간소화된다. 액세스 수정이 단일 ID에 연결되어 있으므로 사용자 역할이 변경되거나 사용자가 조직을 떠날 때 계정을 변경하거나 비활성화하는 과정이 대폭 축소된다. 계정에 Single Sign On을 사용하면 사용자가 ID를 간편하게 관리할 수 있으며, 환경의 보안 기능이 향상된다.

다단계 인증

MFA(다단계 인증)는 전체 인증에 2개 이상의 요소를 요구하여 ID에 추가 보안을 제공한다. 이러한 요소는 세 가지 범주로 분류된다.

  • 사용자가 알고 있는 것 : 암호 또는 보안 질문에 대한 대답
  • 사용자가 소유하고 있는 것 : 알림을 받는 모바일 앱 또는 토큰 생성 디바이스
  • 사용자의 신원 정보 : 여러 모바일 디바이스에서 사용되는 지문 또는 얼굴 검사처럼 생체 인식 속성의 일종

MFA를 사용하면 자격 증명 노출의 영향이 제한되므로 ID 보안이 향상된다. 사용자의 암호를 알고 있는 공격자가 완벽하게 인증하려면 사용자의 휴대폰이나 보안 토큰 생성기를 소유하고 있어야 한다. 단일 요소의 확인을 거친 인증만으로는 부족하며, 공격자는 이 자격증명만을 사용하여 인증할 수 없다. 

Azure AD에서는 MFA가 기본 제공되며, 다른 타사 MFA와 통합된다. 

 

서비스에 ID 제공

일반적으로 서비스에 ID가 있는 것이 좋다. 때때로 모범 사례에 반해, 자격 증명 정보가 구성 파일에 포함된다. 이러한 구성 파일과 관련된 보안이 전혀 없기 때문에 시스템 또는 리포지토리에 대한 액세스 권한을 가진 사람이라면 누구든지 자격 증명에 액세스할 수 있게 되어 위험에 노출된다.

Azure AD는 Azure 서비스의 사용자관리 및 서비스 주체라는 두가지 방법을 통해 이 문제를 해결한다.

서비스 주체

서비스 주체를 이해하려면 ID 및 주체 라는 단어가 ID 관리에 사용되는 방법때문에 먼저 두 단어를 이해하는 것이 좋다.

ID는 인증 가능한 것을 의미한다. 당연히 여기에는 사용자 이름 및 암호를 사용하는 사용자가 포함되지만, 비밀 키 또는 인증서를 사용하여 인증되는 어플리케이션 또는 다른 서버도 포함될 수 있다.

보안 주체는 특정 역할 또는 클레임을 사용하여 작동하는 ID다. 일반적으로 ID와 주체를 동일한 것으로 생각해도 별 무리가 없지만, Linux의 Bash 프롬프트에서 'sudo'를 사용하거나 윈도우에서 '관리자 권한으로 실행'을 사용하는 경우에는 약간 다르다.

서비스 주체는 서비스 또는 어플리케이션에서 사용하는 ID를 말한다. 다른 ID와 마찬가지로 서비스 주체는 할당된 역할일 수 있다.

Azure 서비스에 대한 관리 ID

서비스 주체 만들기는 지루한 과정일 수 있으며, 수많은 접점이 있어서 유지관리가 어려울 수 있다. Azure 서비스의 관리 ID는 훨씬 간단하며 대부분의 작업을 자동으로 처리한다.

관리 ID는 지원되는 모든 Azure 서비스에 대해 즉시 만들 수 있으며, 그 수가 계속해서 늘고있다. 특정 서비스의 관리 ID를 만들면 조직의 Active Directory에 계정이 만들어진다. Azure 인프라는 서비스를 인증하고 계정을 관리하는 작업을 자동으로 처리한다. 그러면 사용자는 인증된 서비스가 다른 Azure 리소스에 안전하게 액세스하도록 허용하는 등 해당 계정을 다른 Azure AD 계정처럼 사용할 수 있다.

 

역할 기반 액세스 제어

역할은 '읽기 전용' 또는 '기여자' 처럼 Azure 서비스 인스턴스에 애겟스하도록 사용자에게 부여될 수 있는 권한 집합이다.

ID는 직접 또는 그룹 멤버 자격을 통해 역할에 매핑된다. 보안주체, 액세스 권한 및 리소스를 분리하면 액세스를 쉽게 관리하고 자세히 제어할 수 있다. 관리자는 필요한 최소한의 권한이 부여되는지 확인할 수 있다.

역할은 개별 서비스 인스턴스 수준에서 부여할 수 있지만 Azure Resource Manager 계층 구조를 따라 아래로 이동하기도 한다.

 

Privileged Identity Management

RBAC(역할 기반 액세스 제어)를 사용한 Azure 리소스 액세스 관리 외에도 인프라 보호에 대한 포괄적인 접근 방식에서는 조직의 변화와 발전에 따라 역할 멤버를 지속적으로 감사하는 방안을 포함하는 것이 좋다. Azure AD PIM(Privileged Identity Managerment)은 역할 할당, 셀프 서비스 및 Just-In-Time 역할 활성화를 감독하고 Azure AD 및 Azure 리소스 액세스를 검토할 수 있는 추가 유료 제품이다.

암호화

대부분 기업에서 가장 가치있는 자산은 데이터가 될 것이다. ㅎㅎ 암호화는 계층화된 보안 전략에서 강력한 최후의 방어선 역할을 한다.

암호화란?

암호화는 권한이 없는 뷰어가 데이터를 읽을 수 없고 사용할 수 없게 만드는 프로세스다. 암호화된 데이터를 사용하거나 읽으려면 암호를 해독해야하고, 암호를 해독하려면 비밀 키를 사용해야 한다. 최상위 수준의 두 가지 암호화 형식으로 대칭 및 비대칭이 있다. 

대칭 암호화

데이터 암호화 및 암호해독에 동일한 키를 사용한다. 데스크톱 암호 관리자 어플리케이션을 생각해보자. 사용자가 암호를 입력하면 사용자의 고유한 개인 키를 사용하여 암호화가 된다. 데이터를 검색해야 하는 경우 동일한 키를 사용하여 데이터가 암호 해독된다.

비대칭 암호화

퍼블릭키와 프라이빗키 쌍을 사용한다. 각 키는 암호화할 수 있지만 단일 키는 고유하게 암호화된 데이터의 암호를 해독할 수 없다. 암호를 해독하려면 페어링된 키가 필요하다. 비대칭 암호화는 TLS(전송 계층 보안, HTTPS에 사용됨) 및 데이터 서명과 같은 용도로 사용된다.

대칭 및 비대칭 암호화는 둘 다 데이터를 적절하게 보호한다. 암호화는 일반적으로 두가지 방법을 사용하는데, 저장데이터 암호화와 전송 중 암호화가 있다.

저장 데이터 암호화

미사용 데이터는 물리적 매체에 저장된 데이터다. 이 데이터는 서버 디스크에 저장된 데이터, 데이터베이스에 저장된 데이터 또는 스토리지 계정에 저장된 데이터일 수 있다. 스토리지 메커니즘과 관계없이 미사용 데이터를 암호화하면, 암호 해독에 필요한 키와 비밀(??)이 없이는 저장된 데이터를 읽을 수 없다. 공격자가 암호화된 데이터가 든 하드 드라이브를 손에 넣더라도 암호화 키에 액세스할 수 없으면 데이터가 쉽게 손상되지 않는다.

암호화된 실제 데이터의 콘텐츠, 사용량 및 조직에서 갖는 중요성은 다를 수 있다. 아래는 암호화된 고객 데이터가 데이터 베이스에 있는 것처럼 보여줄 수 있는 모습을 보여준다.

전송 중 암호화

전송 중인 데이터는 인터넷을 통해 또는 프라이빗 네트워크를 통해 한 위치에서 다른 위치로 능동적으로 이동하는 데이터다. 보안 전송은 여러 다른 계층에서 처리할 수 있다. 네트워크를 통해 데이터를 전송하기 전에 어플리케이션 계층에서 암호화하여 보안 전송을 수행할 수 있다. HTTPS는 전송 암호화 중인 어플리케이션 계층의 예제다.

또한 VPN(가상 프라이빗 네트워크)과 같은 보안 채널을 네트워크 계층에서 설정하여 두 시스템 간에 데이터를 전송할 수도 있다.

전송중인 데이터를 암호화하면 외부 관찰자로부터 데이터를 보호하며, 노출 위험을 제한하면서 데이터를 전송하는 메커니즘이 제공된다.

 

Azure의 암호화

Azure가 여러 서비스에서 데이터를 암호화하도록 설정하는 방법 몇가지를 살펴보자.

1. 원시 스토리지 암호화

미사용 데이터에 Azure 스토리지 서비스 암호화를 사용하면 조직의 보안 및 규정 준수 약정에 맞게 데이터를 보호할 수 있다. 이 기능을 사용하면 Azure 스토리지 플랫폼은 자동으로 데이터를 암호화한 후 Azure Managed Disks, Azure Blob 스토리지, Azure Files 또는 Azure Queue 스토리지에 보관하고 데이터를 암호해독한 후 검색한다. 스토리지 서비스 암호화의 암호화 처리, 미사용 암호화, 암호 해독, 키 관리는 서비스를 사용하여 어플리케이션에 투명하게 처리된다. 

2. 가상 머신 디스크 암호화

스토리지 서비스 암호화는 실제 디스크에 기록된 데이터에 하위 수준 암호화 보호를 제공하지만, 가상 머신의 VHD(가상 하드 디스크)는 어떻게 보호해야 할까? 악의적인 공격자가 Azure 구독에 대한 액세스 권한을 얻어서 가상 머신의 VHD를 탈취한 경우 공격자가 저장된 데이터에 액세스할 수 없게 한다고 하면?

Azure Disk Encryption은 Windows 및 Linux IaaS 가상 머신 디스크를 암호화할 수 있는 기능이다. Azure Disk Encryption은 업계 표준인 Windows의 BitLocker 기능과 Linux의 DM-Crypt 기능을 활용하여 OS 및 데이터 디스크를 위한 볼륨 암호화를 제공한다. 이 솔루션은 고객이 디스크 암호화 키 및 기밀을 제어하고 관리할 수 있도록 Azure Key Vault와 통합된다.

3. 데이터베이스 암호화

TDE(투명한 데이터 암호화)는 악의적인 활동의 위협으로부터 Azure SQL Database 및 Azure Data Warehouse를 보호하는 데 도움이 된다. 어플리케이션에 대한 변경 없이 미사용 데이터베이스, 연결된 백업 및 트랜잭션 로그 파일의 실시간 암호화 및 암호 해독을 수행한다. 새로 배포된 모든 Azure SQL Database 인스턴스에는 기본적으로 TDE가 사용된다.

TDE는 데이터베이스 암호화 키라는 대칭 키를 사용하여 전체 데이터베이스의 스토리지를 암호화한다. 기본적으로 Azure는 논리적 SQL Server 인스턴스마다 고유한 암호화 키를 제공하고 모든 세부 정보를 처리한다. Azure Key Vault에 저장된 키를 통해 BYOK(Bring Your Own Key)도 지원된다.

4. 비밀 암호화

모든 암호화 서비스는 키를 사용하여 데이터를 암호화 및 암호 해독을 한다. 키 자체의 보안은 Azure Key Vault를 사용하여 한다.

Azure Key Vault는 어플리케이션의 기밀정보를 저장하는 중앙 집중식 클라우드 서비스로, Key Vault는 어플리케이션의 비밀을 하나의 중앙 위치에 보관하고 보안, 액세스, 권한 제어 및 액세스 로깅 기능을 제공하므로 어플리케이션의 비밀을 제어하는 데 도움이 된다. 아래와 같은 상황에서 유용하게 사용된다.

  • 비밀 관리 : Key Vault를 사용하여 토큰, 암호, 인증서, API 키 및 기타 비밀에 대한 액세스를 안전하게 저장하고 엄격하게 제어할 수 있다.
  • 키 관리 : Key Vault를 키관리 솔루션으로 사용할 수 있다. Key Vault를 사용하면 데이터를 암호화하는데 사용되는 암호화 키를 쉽게 만들고 제어할 수 있다.
  • 인증서 관리 : Key Vault를 사용하면 Azure 및 내부적으로 연결된 리소스에 사용할 퍼블릭 및 프라이빗 SSL/TLS(Secure Sockets Layer/전송 계층 보안) 인증서를 보다 쉽게 프로비전, 관리 및 배포할 수 있다.
  • HSM(하드웨어 보안 모듈)으로 백업되는 비밀 저장 : 비밀과 키는 소프트웨어 또는 FIPS 140-2 Level 2 검증을 받은 HSM을 통해 보호할 수 있다.

Key Vault 사용시 아래와 같은 이점이 있다. 

  • 어플리케이션 비밀 중앙 집중화
  • 안전하게 비밀 및 키 저장
  • 액세스 및 사용 모니터링
  • 어플리케이션 비밀 관리 최소화
  • 다른 Azure 서비스와 통합

Azure 인증서 개요

TLS(전송계층보안)은 전송중인 웹사이트의 데이터의 암호화를 위한 기본 항목이다. TLS는 인증서를 사용하여 데이터를 암호화하고 해독한다. 그러나 이러한 인증서에는 관리자 관리를 피요로하는 수명 주기가 있다. 웹사이트의 일반적인 보안 문제 중 하나는 TLS 인증서가 만료되어 보안 취약성을 드러내는 것이다.

Azure에서 사용되는 인증서는 x.509 v3로서, 신뢰할 수 있는 인증기관에서 서명할수도 있고 자체 서명될 수도 있다. 자체 서명된 인증서는 해당 작성자에 의해 서명되므로 기본적으로 신뢰할 수 없다. 대부분의 브라우저는 이러한 문제를 무시할 수 있다. 그러나 클라우드 서비스를 개발하고 테스트하는 경우에는 자체 서명된 인증서를 사용해야 한다. 

인증서의 종류

인증서는 두가지 주요 목적으로 Azure에서 사용되며 용도에 따라 특별한 명칭이 부여된다.

  1. 서비스 인증서 : 클라우드 서비스에서 사용
  2. 관리 인증서 : 관리 API를 사용하여 인증하는 데 사용

서비스 인증서

서비스 인증서는 클라우드 서비스에 첨부되며 서비스와의 보안 통신이 가능하게 해준다. 예를들어 웹사이트를 배포하는 경우, 노출된 HTTPS 엔드포인트를 인증할 수 있는 인증서를 제공하려고 한다. 서비스 정의에서 정의된 서비스 인증서는 자동으로 해당 역할 인스턴스를 실행하는 VM에 배포된다.

Azure Portal을 이용하거나 클래식 배포 모델을 사용하여 서비스 인증서를 Azure Portal에 업로드할 수 있다. 서비스 인증서는 특정 클라우드 서비스와 연관된다. 서비스 정의 파일에서 배포에 할당된다.

서비스와는 별도로 서비스 인증서를 관리할 수 있으며, 다른 사람이 관리하도록 할 수 있다. 예를들어 개발자는 IT 관리자가 이전에 Azure로 업로드한 인증서를 참조하는 서비스 패키지를 업로드할 수 있다. IT 관리자는 새 서비스 패키지를 업로드할 필요 없이 서비스 구성을 변경하는 해당 인증서를 관리하고 갱신할 수 있다. 새 서비스 패키지 없이 업데이트가 가능한 이유는 인증서의 논리적 이름과 저장소 이름 및 위치는 서비스 정의파일에 있고 인증서 지문응ㄴ 서비스 구성 파일에 지정되어 있기 때문이다. 인증서를 업데이트하려면 새 인증서를 업로드하고 서비스 구성 파일의 지문 값을 변경하기만 하면 된다.

관리 인증서

관리인증서를 사용하려면 클래식배포 모델로 인증할 수 있다. Visual Studio 또는 Azure SDK와 같은 많은 프로그램 및 도구에서 이러한 인증서를 사용하여 다양한 Azure 서비스의 구성 및 배포를 자동화한다. 

 

인증서를 사용하여 Azure Key Vault 사용

다른 비밀과 마찬가지로 Azure Key Vault에 인증서를 저장할 수 있다. 그러나 키 자격 증명 모음은 일반적인 인증서 관리 이상의 기능을 추가로 제공한다.

  • 키 자격 증명 모음에서 인증서를 만들거나 기존 인증서를 가져올 수 있다.
  • 프라이빗 키 자료와의 상호작용 없이 인증서를 안전하게 저장하고 관리할 수 있다.
  • Key Vault에게 인증서 수명 주기를 관리하도록 지시하는 정책을 만들 수 있다.
  • 인증서의 만료 및 갱신이라는 수명 주기 이벤트에 대한 알림을 위해 연락처 정보를 제공할 수 있다.
  • 선택한 발급자 - 키 자격 증명 모음 파트너 x509 인증서 공급자/인증서 기관을 통해 자동 갱신할 수 있다.

네트워크 보호

공격 및 무단 액세스로부터 네트워크를 보호하는 것은 아키텍처의 중요한 부분이다. 여기서는 네트워크 보안의 특징, 계층화된 접근 방식을 아키텍처에 통합하는 방법 및 Azure에서 네트워크 보안을 환경에 제공하는 방법을 살펴보자.

네트워크 보안에 대한 계층화된 접근 방식

이 모듈 전체에서 공통적으로 다루는 주제는 보안에 대한 계층화된 접근 방식의 중요성이다. 이 접근 방식은 네트워크 계층에서도 계속 권장된다. 네트워크 경계 보호에만 집중하거나 네트워크 내부의 서비스간 네트워크 보안에 집중하는 것만으로는 충분하지 않다. 계층화된 접근 방식은 여러 보호 수준을 제공하므로 공격자가 한 계층을 돌파하더라도 추가 보호가 작동하므로 추가적인 공격이 제한된다.

Azure가 어떤 계층화된 접근 방식 도구로 네트워크 공간을 보호하는지 살펴보자.

인터넷 보호

네트워크 경계에서 시작하는 경우는 인터넷 공격을 제한하고 제거하는 것에 집중한다. 먼저 인터넷에 견결되는 리소스를 평가하고 필요한 경우에만 인바운드 및 아웃바운드 통신을 허용하는 것이 좋다. 모든 종류의 인바운드 네트워크 트래픽을 허용하는 리소스를 식별하고, 리소스를 반드시 필요한 포트/프로토콜로 제한해야 한다. 이 정보는 Azure Security Center에서 살펴보면 좋다. 네트워크 보안 그룹이 연결되지 않은 인터넷 연결 리소스와 방화벽의 보호를 받지 않는 리소스를 식별하기 때문이다.

방화벽이란?

방화벽은 각 요청에 원래 IP 주소에 따라 서버 엑세스 권한을 부여하는 서비스다. IP 주소 범위를 지정하는 방화벽 규칙을 만든다. 이러한 권한이 부여된 IP 주소의 클라이언트만 서버에 엑세스할 수 있다. 일반적으로 방화벽 규칙에는 특정 네트워크 프로토콜 및 포트 정보도 포함된다.

경계에서 인바운드 보호를 제공할 때 아래와 같은 선택사항이 있다.

  • Azure Firewall : Azure Virtual Network 리소스를 보호하는 관리되는 클라우드 기반 네트워크 보안 서비스. 고가용성 및 무제한 클라우드 확장성이 내장되어 있는 서비스 형태의 완전한 상태 저장 방화벽이다. Azure Firewall은 비-HTTP/S 프로토콜에 대한 인바운드 보호를 제공한다. 비-HTTP/S 프로토콜의 예로는 RDP(원격 데스크톱 프로토콜), SSH(Secure Shell) 및 FTP(파일 전송 프로토콜)를 들 수 있다. 또한 모든 포트 및 프로토콜에 아웃바운드 네트워크 수준 보호를 제공하고 아웃바운드 HTTP/S에 어플리케이션 수준 보호를 제공한다.
  • Azure Application Gateway : 웹사이트의 널리 알려진 취약성으로부터 보호하는 WAF(웹 어플리케이션 방화벽)이 포함된 부하분산장치. HTTP 트래픽을 보호하도록 설계되어있다.
  • NVA(네트워크 가상 어플라이언스) : HTTP가 아닌 서비스 또는 고급 구성에 적합한 옵션이며, 하드웨어 방화벽 어플라이언스와 비슷하ㅏㄷ.

DDoS (서비스 거부 공격) 방지

인터넷에 공개된 모든 리소스는 서비스 거부 공격을 받을 위험이 있다. 이 유형의 공격은 많은 요청을 보내 리소스의 속도를 저해하거나 무응답 상태로 만들어 네트워크 리소스에 부담을 주는 것이다.

Azure DDoS Protection을 어플리케이션 설계 모범 사례와 결합하면 DDoS 공격을 방어하는 데 도움이 된다. DDoS Protection은 Microsoft의 유연한 대규모 글로벌 네트워크를 활용하여 모든 Azure 지역에 DDoS 완화 능력을 제공한다. Azure DDoS Protection 서비스는 Azure 네트워크 에지의 트래픽이 서비스의 가용성에 영향을 주기 전에 해당 트래픽을 모니터링하여 Azure 어플리케이션을 보호한다. 공격이 탐지되면 몇 분 이내에 Azure Monitor 메트릭을 사용한 알림을 받는다.

Azure DDoS Protection은 아래 서비스 계층을 제공한다.

  • 기본 : 기본 서비스 계층은 Azure 플랫폼의 일부로 자동으로 사용하도록 설정된다. 일반적인 네트워크 수준 공격에 대한 항시 트래픽 모니터링과 실시간 완화는 Microsoft의 온라인 서비스에서 사용하는 것과 동일한 방어를 제공한다. Azure 글로벌 네트워크는 Azure 지역에 대한 공격 트래픽을 분산하고 완화하는데 사용된다.
  • 표준 : 표준 서비스 계층은 Azure Virtual Network 리소스에 맞게 특별히 조정된 추가적인 완화 기능을 제공한다. DDoS Protection 표준은 간단히 사용하도록 설정할 수 있고 어플리케이션을 변경할 필요가 없다. 보호 정책은 전용 트래픽 모니터링 및 기계학습 알고리즘을 통해 조정된다. 정책은 Azure Load Balancer, Application Gateway 등의 가상 네트워크에 배포된 리소스와 연결된 공용 IP 주소에 적용된다. DDoS 표준 보호는 아래와 같은 유형의 공격을 완화할 수 있다.
    • 대규모 공격 
    • 프로토콜 공격 : 계층 3 및 계층 4 프로토콜 스택의 취약점을 악용하여 대상을 액세스 불능 상태로 만드는 것
    • 리소스(어플리케이션) 계층 공격 : 대상 웹 어플리케이션 패킷을 공격하여 호스트 간 데이터 전송을 방해

 

가상 네트워크 내부의 트래픽 제어

가상 네트워크 보안

VNet(가상 네트워크) 내에서는 꼭 필요한 곳에서만 리소스 간 통신이 이루어지도록 제한해야 한다. 가상 머신 간의 통신에서는 NSG(네트워크 보안 그룹)를 통해 불필요한 통신을 제한하는 것이 중요하다.

네트워크 보안 그룹을 사용하면 Azure 가상 네트워크의 Azure 리소스와 주고받는 네트워크 트래픽을 필터링할 수 있다. 각 NSG에는 원본 및 대상 IP 주소, 포트 및 프로토콜을 기준으로 리소스와 주고받는 트래픽을 필터링할 수 있는 여러 개의 인바운드 및 아웃바운드 보안 규칙이 포함될 수 있다. 네트워크 인터페이스 및 서브넷과 허용되거나 거부되는 통신의 목록을 제공하며 완전히 사용자 지정할 수 있다.

서비스 엔드포인트에 대한 액세스를 제한하여 서비스에 대한 공용 인터넷 액세스를 완전히 제거할 수 없다. 서비스 엔드포인트를 사용하면 Azure 서비스 액세스가 가상 네트워크로 제한될 수 있다.

네트워크 통합

온프레미스 네트워크에서 통신을 제공하거나, Azure의 서비스 간 통신을 향상시키기 위해 기존 네트워크 인프라를 통합해야 하는 경우가 자주 있다. 이러한 통합을 처리하고 네트워크 보안을 향상할 수 있는 몇가지 방법이 있다.

VPN(가상 사설망) 연결은 네트워크 간에 보안 통신 채널을 설정하는 일반적인 방법이다. 네트워크와 Azure VNet 간에 보안 통신을 제공할 수 있는 방법 중의 하나는 Azure Virtual Netowrk와 온프레미스 VPN 디바이스를 연결하는 것이다.

네트워크와 Azure 간에 전용 프라이빗 연결을 제공하려면 Azure ExpressRoute를 사용한다. ExpressRoute를 사용하면 연결 공급자가 지원하는 프라이빗 연결을 통해 온프레미스 네트워크를 Microsoft 클라우드로 확장할 수 있다. ExpressRoute를 사용하면 Microsoft Azure, Office 365 및 Dynamic 365와 같은 Microsoft 클라우드 서비스에 대한 연결을 설정할 수 있다. ExpressRoute 연결은 공용 인터넷 대신 프라이빗 회로를 통해 이 트래픽을 전송하여 온프레미스 통신의 보안을 개선한다. 최종 사용자가 공용 인터넷을 통해 이 서비스에 액세스하도록 허용할 필요가 없으며, 어플라이언스를 통해 이 트래픽을 전송하여 트래픽을 추가로 검사할 수 있다.

Azure Advanced Threat Protection

Azure ATP(Azure Advanced Threat Protection) 는 고객의 조직을 노리는 고급 위협, 손상된 ID 및 악의적인 내부자 작업을 식별, 탐지, 조사하도록 도와주는 클라우드 기반 보안 솔루션입니다.

Azure ATP는 알려진 악의적인 공격과 기법, 보안 문제 및 네트워크 위험을 탐지할 수 있습니다.

Azure ATP 구성 요소

Azure ATP는 여러 구성 요소로 구성됩니다.

Azure ATP 포털

Azure ATP는 자체 포털을 갖고 있으며, 이 포털을 통해 의심스러운 활동을 모니터링하고 적절하게 대응할 수 있습니다. Azure ATP 포털을 통해 Azure ATP 인스턴스를 만들고, Azure ATP 센서에서 받은 데이터를 볼 수 있습니다. 포털을 사용하여 네트워크 환경의 위협을 모니터링, 관리 및 조사할 수도 있습니다. https://portal.atp.azure.com 에서 Azure ATP 포털에 로그인할 수 있습니다. 로그인할 수 있으려면 Azure ATP 포털에 액세스할 수 있는 Azure AD 보안 그룹에 사용자 계정을 할당해야 합니다.

Azure ATP 센서

Azure ATP 센서는 도메인 컨트롤러에 직접 설치됩니다. 이 센서는 전용 서버 없이 또는 포트 미러링을 구성하지 않고도 도메인 컨트롤러 트래픽을 모니터링합니다.

Azure ATP 클라우드 서비스

Azure ATP 클라우드 서비스는 Azure 인프라에서 실행되며 현재 미국, 유럽 및 아시아에 배포됩니다. Azure ATP 클라우드 서비스는 Microsoft 인텔리전트 보안 그래프에 연결됩니다.

Azure Advanced Threat Protection 구매

Azure ATP는 EMS E5(Enterprise Mobility + Security E5) 제품군의 일부와 독립 실행형 라이선스로 제공됩니다. Enterprise Mobility + Security 가격 책정 옵션 페이지에서 직접 또는 CSP(클라우드 솔루션 공급자) 라이선스 모델을 통해 라이선스를 얻을 수 있습니다. Azure Portal을 통해 구입할 수 없습니다.

 

애플리케이션 수명 주기 관리 솔루션에 대한 보안 고려 사항 이해

Microsoft SDL(보안 개발 수명 주기) 은 개발 프로세스의 모든 단계에서 보안 및 프라이버시 고려 사항을 소개합니다. 이를 통해 개발자는 보안 수준이 높은 소프트웨어를 빌드하고 보안 규정 준수 요구 사항을 해결하고 개발 비용을 절감할 수 있습니다. SDL의 지침, 모범 사례, 도구 및 프로세스는 Microsoft에서 내부적으로 사용하여 더 안전한 제품 및 서비스를 빌드하는 데 사용되는 방법입니다.

2008에서 SDL을 처음으로 공유했으므로 클라우드 서비스, IoT 및 AI와 같은 새로운 시나리오를 처리하기 위해 사례가 지속적으로 업데이트되었습니다.

교육 제공

보안은 모두에게 필요합니다. 개발자, 서비스 엔지니어, 프로그램 및 프로젝트 관리자는 보안 기본 사항을 이해하고 있어야 합니다. 비즈니스 요구를 해결하고 사용자 가치를 제공하면서도 제품의 보안을 강화하기 위해 소프트웨어 및 서비스에 보안을 구축하는 방법을 알아야 합니다. 효과적인 교육은 보안 정책, SDL 사례, 표준 및 소프트웨어 보안 요구 사항을 보완하고 더욱 강화하며, 데이터 또는 새로 제공되는 기술 기능을 통해 얻은 인사이트를 기반으로 이루어집니다.

보안은 모두에게 중요한 문제이지만, 모든 사람이 보안 전문가이거나 숙련된 침투 테스터가 되어야 하는 것은 아닙니다. 하지만 모두가 공격자의 관점과 목표 그리고 가능한 공격 수법을 파악할 수 있도록 한다면 모든 사람의 관심을 끌고 전체적인 이해도를 높이는 데 도움이 될 것입니다.

보안 요구 사항 정의

보안 및 프라이버시는 매우 안전한 애플리케이션과 시스템 개발의 기본적인 측면입니다. 사용 중인 개발 방법과 관계없이, 필요한 기능 변경과 위협 환경의 변화를 처리하도록 보안 요구 사항을 지속적으로 업데이트해야 합니다. 보안 요구 사항을 정의할 최적의 시점은 초기 디자인 및 계획 단계입니다. 초기 계획을 통해 개발팀은 중단을 최소화하는 방식으로 보안을 통합할 수 있습니다.

보안 요구 사항에 영향을 주는 요인은 다음과 같지만, 이에 국한되지 않습니다.

  • 법률 및 업계 요구 사항
  • 내부 표준 및 코딩 방식
  • 이전 인시던트 검토
  • 알려진 위협

이러한 요구 사항은 작업 추적 시스템 또는 엔지니어링 파이프라인에서 파생된 원격 분석을 통해 추적해야 합니다.

메트릭 및 규정 준수 보고 정의

조직에서 허용되는 최소 보안 품질 수준을 정의하고 엔지니어링 팀이 해당 조건의 충족을 담당하는 것이 중요합니다. 이러한 기대치를 조기에 정의하면 팀에서 보안 문제와 관련된 위험을 이해하고, 개발 과정에서 보안 결함을 파악하고 해결하며, 프로젝트 전체에 표준을 적용하는 데 도움이 됩니다. 적절한 보안 수준을 설정하는 것은 보안 취약점의 심각도 임계값을 명확하게 정의하는 작업을 포함하며, 취약점이 발견되는 경우 조치 계획을 세우는 데 도움이 됩니다. 예를 들어, “중대” 또는 “중요” 심각도 등급으로 발견되는 알려진 취약점은 모두 지정된 시간 프레임 내에 해결해야 합니다.

KPI(핵심 성과 지표)를 추적하고 보안 작업이 완료되었는지 확인하기 위해 조직에서 사용하는 버그 추적 및/또는 작업 추적 메커니즘(예: Azure DevOps)을 통해 보안 오류 및 보안 작업 항목을 보안으로 명확하게 지정하고 적절한 보안 심각도로 표시해야 합니다. 이 추적을 통해 보안 작업을 정확하게 추적하고 보고할 수 있습니다.

메트릭 및 규정 준수 보고 정의에 대한 자세한 내용은 다음을 참조하세요.

위협 모델링 수행

위협 모델링은 보안상 위험할 수 있는 환경에서 사용해야 합니다. 이를 통해 개발팀은 계획한 운영 환경의 컨텍스트에서 구조화된 방식으로 디자인의 보안 영향을 고려하고 문서화하고 논의할 수 있습니다. 구조적 접근 방식을 위협 시나리오에 적용하면 팀이 보다 효과적이고 비용 효율적으로 보안 취약점을 식별하고 해당 위협에서 위험 요인을 확인한 후, 보안 기능을 선택하고 적절한 완화 방법을 정할 수 있습니다. 구성 요소, 애플리케이션 또는 시스템 수준에서 위협 모델링을 적용할 수 있습니다.

자세한 내용은 위협 모델링을 참조하세요.

디자인 요구 사항 설정

SDL은 엔지니어가 보다 안전한 기능을 구현하는 데 도움을 주는 보증 활동에 대해 일상적으로 고민합니다. 따라서 해당 기능은 보안을 위해 적절히 설계됩니다. 이 보증을 달성하기 위해 엔지니어는 일반적으로 암호화, 인증 및 로깅과 같은 보안 기능을 사용합니다. 대부분의 경우에는 보안 기능을 선택 또는 구현하는 작업이 너무 복잡해서 디자인 또는 구현의 선택으로 인해 취약성을 유발하는 것으로 입증되었습니다. 따라서 그러한 기능이 제공하는 보호에 대해 일관성 있게 이해하고 적용하는 것이 중요합니다.

암호화 표준 정의 및 사용

모바일 및 클라우드 컴퓨팅이 증가함에 따라 보안에 민감한 정보 및 관리와 제어 데이터를 비롯한 모든 데이터가 전송 또는 저장 과정에서 의도하지 않게 공개 또는 변경되지 않도록 보호하는 것이 중요합니다. 암호화는 일반적으로 이런 보호를 얻기 위해 사용됩니다. 그러나 암호화의 어떤 측면을 사용하든 잘못된 선택은 치명적인 결과를 가져올 수 있습니다. 따라서 암호화 구현의 모든 요소에 대한 구체적인 정보를 제공하는 명확한 암호화 표준을 개발하는 것이 가장 좋습니다.

암호화는 전문가에게 맡겨야 합니다. 업계의 점검을 거친 암호화 라이브러리를 사용하고 필요한 경우 쉽게 교체할 수 있는 방식으로 구현되는지 확인하는 것이 좋습니다.

암호화에 대한 자세한 내용은 Microsoft SDL 암호화 권장 사항 백서를 참조하세요.

타사 구성 요소를 사용하여 보안 위험 관리

오늘날 대부분의 소프트웨어 프로젝트는 타사 구성 요소(상용 및 오픈 소스 모두)를 사용하여 빌드됩니다. 사용할 타사 구성 요소를 선택할 때는 해당 구성 요소의 보안 취약성이 통합되는 더 큰 시스템의 보안성에 영향을 미칠 수 있는 영향을 이해하는 것이 중요합니다. 해당 구성 요소의 정확한 인벤토리와 새로운 취약성이 발견되는 경우의 대응 계획을 갖추고 있으면 이러한 위험을 완화하는 데 큰 도움이 됩니다. 그러나 조직의 위험 허용 범위, 사용되는 구성 요소의 유형 및 보안 취약성의 잠재적 영향에 따라 추가 유효성 검사도 고려해야 합니다.

타사 구성 요소를 사용하는 경우의 보안 위험 관리에 대해 자세히 알아보세요.

승인된 도구 사용

승인된 도구 목록과 컴파일러/링커 옵션 및 경고와 같은 관련 보안 검사를 정의하고 게시합니다. 엔지니어는 최신 버전의 승인된 도구(예: 컴파일러 버전)를 사용하고 새로운 보안 분석 기능 및 보호를 활용하기 위해 노력해야 합니다.

자세한 내용은 다음을 참조하세요.

정적 분석 보안 테스트 수행

컴파일 전에 소스 코드 분석으로 확장성이 뛰어난 보안 코드 검토 방법을 제공하고, 보안 코딩 정책을 준수하도록 할 수 있습니다. SAST(정적 분석 보안 테스트)는 일반적으로 소프트웨어를 빌드하거나 패키징할 때마다 커밋 파이프라인에 통합되어 취약점을 식별합니다. 그러나 일부 서비스는 개발자 환경에 통합되어 안전하지 않거나 다른 금지된 기능의 존재 여부와 같은 특정 결함을 찾아 개발자가 활발하게 코딩하는 동안 해당 기능을 보다 안전한 대체 항목으로 대체합니다. 모든 솔루션에 알맞은 크기는 없습니다. 개발팀은 SAST를 수행할 최적의 빈도를 결정하고 적절한 보안 검사를 통해 생산성을 분산할 수 있도록 여러 가지 전략을 배포하는 것이 좋습니다.

자세한 내용은 다음을 참조하세요.

동적 분석 보안 테스트 수행

완전히 컴파일되거나 패키징된 소프트웨어에 대한 런타임 확인을 통해 모든 구성 요소가 통합되고 실행되어야만 명확해지는 기능을 검사합니다. 이런 확인은 일반적으로 테스트는 도구, 미리 빌드된 공격 모음 또는 메모리 손상, 사용자 권한 문제 및 기타 중요한 보안 문제에 대한 애플리케이션 동작을 특별히 모니터링하는 도구를 사용하여 이루어집니다. SAST와 마찬가지로 모든 상황에 맞는 단일 솔루션은 없습니다. 웹앱 검색 도구와 같은 일부 도구는 CI/CD 파이프라인에 더욱 쉽게 통합할 수 있는 반면 퍼지와 같은 DAST(동적 애플리케이션 보안 테스트)에는 다른 접근 방법이 필요합니다.

자세한 내용은 다음을 참조하세요.

침투 테스트 수행

침투 테스트는 해커의 행동을 시뮬레이트하는 숙련된 보안 전문가가 수행하는 소프트웨어 시스템에 대한 보안 분석입니다. 침투 테스트의 목적은 코딩 오류, 시스템 구성 오류 또는 기타 운영 배포 약점으로 인해 발생할 수 있는 잠재적 취약성을 파악하는 것입니다. 침투 테스트는 일반적으로 가장 광범위한 취약점을 발견하며, 가능한 것보다 더 높은 수준의 분석을 제공하기 위해 자동 및 수동 코드 검토와 함께 수행되는 경우가 많습니다.

자세한 내용은 다음을 참조하세요.

표준 인시던트 대응 프로세스 구축

인시던트 대응 계획을 준비하는 것은 시간이 지남에 따라 발생할 수 있는 새로운 위협을 해결하는 데 중요하며, 조직의 전용 PSIRT(Product Security Incident Response Team)와 함께 계획을 만들어야 합니다. 인시던트 대응 계획은 다음과 같아야 합니다.

  • 보안 응급 상황 발생 시 연락할 담당자를 포함합니다.
  • 조직 내 다른 그룹에서 상속된 코드 및 타사 코드에 대한 계획을 비롯하여 보안 서비스 제공을 위한 프로토콜을 설정해야 합니다.
  • 필요하기 전에 테스트해야 합니다.

인시던트 대응에 대한 자세한 내용은 다음을 참조하세요.

개발자는 개발 프로세스의 모든 단계에서 표준화된 보안 및 규정 준수 고려 사항을 도입하여 제품과 서비스의 취약성 발생 가능성을 줄이고 동일한 보안 실수의 반복을 방지할 수 있습니다. 마찬가지로, 운영 수명 주기 전체에서 보안 통합은 해당 제품 및 서비스의 무결성을 유지하는 데 도움이 됩니다. 운영 보안 보증 사례는 개발 프로세스에 맞춰 조정해야 하며, 이를 통해 팩트 후에 심사 및 대응에 소요되는 시간과 비용을 절감하고 고객에게 제품이 높은 보안 수준을 사용함을 보증할 수 있습니다.

 

출처 : https://docs.microsoft.com/ko-kr/learn/modules/intro-to-security-in-azure/

 

Azure의 보안, 책임 및 신뢰 - Learn

클라우드에서 작업할 때 인프라와 데이터를 보호하기 위한 기본 개념을 설명합니다. 내게 어떤 책임이 있고 Azure에서는 무엇을 관리하는지 이해합니다.

docs.microsoft.com

 

'Computer Engineering > Cloud Computing' 카테고리의 다른 글

[Azure Certi] AZ-900 Certi 준비 (8) - Azure 네트워킹 옵션  (0) 2020.05.27
[Azure Certi] AZ-900 Certi 준비 (7) - Azure 데이터 스토리지 옵션  (0) 2020.05.25
[Azure Certi] AZ-900 Certi 준비 (6) - Azure 컴퓨팅 개념  (0) 2020.05.24
[Azure Certi] AZ-900 Certi 준비 (5) - Azure 아키텍처 및 서비스 보증에 대하여  (0) 2020.05.23
[Azure Certi] AZ-900 Certi 준비 (4) - Azure Cloud Shell을 이용하여 App Servcie에 엑세스  (0) 2020.05.23

티스토리툴바