다음을 통해 공유

보안 제어: ID 관리

ID 관리에서는 애플리케이션, 조건부 액세스, 계정 변칙 모니터링을 위해 Single Sign-On, 강력한 인증, 관리 ID(및 서비스 원칙)를 사용하여 ID 및 액세스 관리 시스템을 사용하는 보안 ID 및 액세스 제어를 설정하는 컨트롤을 다룹니다.

IM-1: 중앙 집중식 ID 및 인증 시스템 사용

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
6.7, 12.5 교류-2, 교류-3, IA-2, IA-8 7.2, 8.3

보안 원칙: 중앙 집중식 ID 및 인증 시스템을 사용하여 클라우드 및 비 클라우드 리소스에 대한 조직의 ID 및 인증을 제어합니다.

Azure 지침: Azure AD(Azure Active Directory)는 Azure의 ID 및 인증 관리 서비스입니다. 다음에서 조직의 ID 및 인증을 제어하도록 Azure AD를 표준화해야 합니다.

  • Azure Storage, Azure Virtual Machines(Linux 및 Windows), Azure Key Vault, PaaS 및 SaaS 애플리케이션과 같은 Microsoft 클라우드 리소스.
  • Azure의 애플리케이션, 회사 네트워크 리소스에서 실행되는 타사 애플리케이션 및 타사 SaaS 애플리케이션과 같은 조직의 리소스.
  • 중앙에서 관리되는 일관된 ID 전략을 위해 Active Directory의 엔터프라이즈 계정을 Azure AD와 동기화합니다.

적용되는 Azure 서비스의 경우 로컬 인증 방법을 사용하지 말고 Azure Active Directory를 사용하여 서비스 인증을 중앙 집중화합니다.

참고: 기술적으로 가능한 즉시 온-프레미스 Active Directory 기반 애플리케이션을 Azure AD로 마이그레이션해야 합니다. Azure AD Enterprise Directory, Business to Business 구성 또는 Business to Consumer 구성일 수 있습니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: AWS IAM(ID 및 액세스 관리)은 AWS의 기본 ID 및 인증 관리 서비스입니다. AWS IAM을 사용하여 AWS ID 및 액세스 관리를 관리합니다. 또는 AWS 및 Azure SSO(단일 Sign-On)를 통해 Azure AD를 사용하여 AWS의 ID 및 액세스 제어를 관리하여 두 클라우드 플랫폼에서 중복 계정을 별도로 관리하지 않도록 할 수도 있습니다.

AWS는 AWS 리소스에 액세스하기 위해 중복 계정을 만들지 않도록 회사의 타사 ID(예: Windows Active Directory 또는 기타 ID 저장소)를 AWS ID와 연결할 수 있는 단일 Sign-On 지원합니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: Google Cloud의 IAM(ID 및 액세스 관리) 시스템은 Google Cloud Id 계정에 사용되는 Google Cloud의 기본 ID 및 인증 관리 서비스입니다. Google Cloud IAM을 사용하여 GCP ID 및 액세스 관리를 관리합니다. 또는 Google Cloud Identity 및 Azure Sigle Sign-On(SSO)를 통해 Azure AD를 사용하여 GCP의 ID 및 액세스 제어를 관리하여 뮤틀리 클라우드 환경에서 중복 계정을 별도로 관리하지 않도록 할 수도 있습니다.

Google Cloud Identity는 모든 Google 서비스의 ID 공급자입니다. GCP 리소스에 액세스하기 위해 중복 계정을 만들지 않도록 회사의 타사 ID(예: Windows Active Directory 또는 기타 ID 저장소)를 Google Cloud ID와 연결할 수 있는 단일 Sign-On 지원합니다.

참고: Google 클라우드 디렉터리 동기화 사용. Google은 대부분의 엔터프라이즈 LDAP 관리 시스템과 통합되고 일정에 따라 ID를 동기화하는 커넥터 도구를 제공합니다. 클라우드 ID 계정을 구성하고 Google Cloud Directory Sync를 사용하면 사용자, 그룹 및 사용자 프로필, 별칭 등을 포함한 사용자 계정 중 로컬 ID 관리 시스템과 GCP 시스템 간에 일정에 따라 동기화할 사용자 계정을 구성할 수 있습니다.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-2: ID 및 인증 시스템 보호

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

보안 원칙: 조직의 클라우드 보안 사례에서 높은 우선 순위로 ID 및 인증 시스템을 보호합니다. 일반적인 보안 제어는 다음과 같습니다.

  • 권한 있는 역할 및 계정 제한
  • 모든 권한 있는 액세스에 대해 강력한 인증 필요
  • 고위험 활동 모니터링 및 감사

Azure 지침: Azure AD 보안 기준 및 Azure AD ID 보안 점수를 사용하여 Azure AD ID 보안 상태를 평가하고 보안 및 구성 격차를 수정합니다. Azure AD ID 보안 점수는 다음 구성에 대해 Azure AD를 평가합니다.

  • 제한된 관리 역할 사용
  • 사용자 위험 정책 켜기
  • 둘 이상의 전역 관리자 지정
  • 레거시 인증을 차단하는 정책 사용
  • 모든 사용자가 보안 액세스를 위해 다단계 인증을 완료할 수 있는지 확인
  • 관리자 역할용 MFA 필요
  • 셀프 서비스 비밀번호 재설정을 활성화
  • 암호를 만료하지 마세요.
  • 로그인 위험 정책 켜기
  • 사용자가 관리되지 않는 애플리케이션에 동의를 부여하도록 허용하지 않음

Azure AD ID 보호를 사용하여 ID 기반 위험을 감지, 조사 및 수정합니다. 마찬가지로 온-프레미스 Active Directory 도메인을 보호하려면 Defender for Identity를 사용합니다.

참고: 온-프레미스 Active Directory 및 타사 기능 및 호스트하는 인프라(예: 운영 체제, 네트워크, 데이터베이스)를 포함하여 다른 모든 ID 구성 요소에 대해 게시된 모범 사례를 따릅니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: 다음 보안 모범 사례를 사용하여 AWS IAM을 보호합니다.

  • PA-5에 설명된 대로 긴급 액세스를 위한 AWS 계정 루트 사용자 액세스 키 설정(응급 액세스 설정)
  • 액세스 할당에 대한 최소 권한 원칙을 따릅니다.
  • IAM 그룹을 활용하여 개별 사용자 대신 정책을 적용합니다.
  • 모든 사용자에 대해 IM-6(강력한 인증 제어 사용)의 강력한 인증 지침을 따릅니다.
  • AWS 조직 SCP(서비스 제어 정책) 및 권한 경계 사용
  • IAM Access Advisor를 사용하여 서비스 액세스 감사
  • IAM 자격 증명 보고서를 사용하여 사용자 계정 및 자격 증명 상태 추적

참고: Azure AD를 사용하여 AWS ID 및 액세스를 관리하는 경우 다른 ID 및 인증 시스템(예: Azure AD 보안 기준)이 있는 경우 게시된 모범 사례를 따릅니다.

AWS 구현 및 추가 컨텍스트:

  • IAM 보안 모범 사례
  • IAM 액세스 관리자
  • IAM 자격 증명 보고서

GCP 지침: 다음 보안 모범 사례를 사용하여 조직의 Google Cloud IAM 및 클라우드 ID 서비스를 보호합니다.

  • PA-5("긴급 액세스 설정")의 권장 사항에 따라 응급 액세스를 위한 슈퍼 관리자 계정을 설정합니다.
  • 슈퍼 관리자 이메일 주소(Google Workspace 또는 Cloud Identity 슈퍼 관리자 계정)를 만들고 긴급 복구가 필요한 경우 이 계정은 특정 사용자와 관련이 없어야 합니다.
  • 최소 권한 및 의무 원칙 분리를 따릅니다.
  • 일상적인 활동에 슈퍼 관리자 계정을 사용하지 마세요.
  • Google 클라우드 ID 그룹을 활용하여 개별 사용자에게 정책을 적용하는 대신 정책을 적용합니다.
  • 상승된 권한을 가진 모든 사용자에 대해 IM-6("강력한 인증 제어 사용")에 설명된 대로 강력한 인증 지침을 따릅니다.
  • IAM 정책을 사용하여 리소스에 대한 액세스 제한
  • 조직 정책 서비스를 사용하여 리소스에 대한 제약 조건 제어 및 구성
  • 클라우드 감사 로그 내에서 IAM 감사 로깅을 사용하여 권한 있는 활동을 리뷰하세요.

참고: 다른 신원 및 인증 시스템을 사용하는 경우 게시된 모범 사례를 따르십시오. 예를 들어, Azure AD를 사용하여 GCP 신원 및 액세스를 관리하는 경우 Azure AD 보안 기준을 따르십시오.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-3: 애플리케이션 ID를 안전하고 자동으로 관리

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
해당 없음(N/A) AC-2, AC-3, IA-4, IA-5, IA-9 해당 없음(N/A)

보안 원칙: 리소스에 액세스하고 코드를 실행하는 애플리케이션에 대한 사용자 계정을 만드는 대신 관리되는 애플리케이션 ID를 사용합니다. 관리되는 애플리케이션 ID는 자격 증명 노출을 줄이는 등의 이점을 제공합니다. 자격 증명 회전을 자동화하여 ID의 보안을 보장합니다.

Azure 지침: Azure AD 인증을 지원하는 Azure 서비스 및 리소스에 인증할 수 있는 Azure 관리 ID를 사용합니다. 관리 ID 자격 증명은 완전히 관리되고, 회전되며, 플랫폼에 의해 보호되어 소스 코드 또는 구성 파일에서 하드 코딩된 자격 증명을 방지합니다.

관리 ID를 지원하지 않는 서비스의 경우 Azure AD를 사용하여 리소스 수준에서 권한이 제한된 서비스 주체를 만듭니다. 인증서 자격 증명을 사용하여 서비스 주체를 구성하고 인증을 위해 클라이언트 비밀로 대체하는 것이 좋습니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: 이 기능을 지원하는 리소스에 대한 사용자 계정을 만드는 대신 AWS IAM 역할을 사용합니다. IAM 역할은 백 엔드의 플랫폼에서 관리되며 자격 증명은 일시적이고 자동으로 회전됩니다. 이렇게 하면 소스 코드 또는 구성 파일에서 애플리케이션 및 하드 코딩된 자격 증명에 대한 장기 액세스 키 또는 사용자 이름/암호를 만들지 않습니다.

IAM 역할에 대한 사용자 고유의 역할 권한을 사용자 지정하는 대신 AWS 서비스 간 액세스를 위해 미리 정의된 권한 정책과 연결된 서비스 연결 역할을 사용할 수 있습니다.

참고: IAM 역할을 지원하지 않는 서비스의 경우 액세스 키를 사용하지만 IM-8과 같은 보안 모범 사례를 따라 자격 증명 및 비밀 노출을 제한하여 키를 보호합니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: 이 기능을 지원하는 리소스에 대한 사용자 관리 계정을 만드는 대신 Google 관리 서비스 계정을 사용합니다. Google 관리 서비스 계정은 백 엔드의 플랫폼에서 관리되며 서비스 계정 키는 일시적이고 자동으로 회전됩니다. 이렇게 하면 소스 코드 또는 구성 파일에서 애플리케이션 및 하드 코딩된 하드 코딩 자격 증명에 대한 장기 액세스 키 또는 사용자 이름/암호를 만들지 않습니다.

정책 인텔리전스를 사용하여 서비스 계정에 대한 의심스러운 활동을 이해하고 인식합니다.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-4: 서버 및 서비스 인증

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
해당 없음(N/A) IA-9 해당 없음(N/A)

보안 원칙: 신뢰할 수 있는 서버 및 서비스에 연결하도록 클라이언트 쪽에서 원격 서버 및 서비스를 인증합니다. 가장 일반적인 서버 인증 프로토콜은 TLS(전송 계층 보안)입니다. 여기서 클라이언트 쪽(종종 브라우저 또는 클라이언트 디바이스)은 신뢰할 수 있는 인증 기관에서 서버의 인증서를 발급했는지 확인하여 서버를 확인합니다.

참고: 서버와 클라이언트가 서로 인증할 때 상호 인증을 사용할 수 있습니다.

Azure 지침: 대부분의 Azure 서비스는 기본적으로 TLS 인증을 지원합니다. 기본적으로 TLS 인증을 지원하지 않거나 TLS를 사용하지 않도록 지원하는 서비스의 경우 서버/클라이언트 인증을 지원하도록 항상 사용하도록 설정되어 있는지 확인합니다. 또한 클라이언트 애플리케이션은 핸드셰이크 단계에서 서버/클라이언트 ID(신뢰할 수 있는 인증 기관에서 발급한 서버의 인증서를 확인)를 확인하도록 설계되어야 합니다.

참고: API Management 및 API Gateway와 같은 서비스는 TLS 상호 인증을 지원합니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: 대부분의 AWS 서비스는 기본적으로 TLS 인증을 지원합니다. 기본적으로 TLS 인증을 지원하지 않거나 TLS를 사용하지 않도록 지원하는 서비스의 경우 서버/클라이언트 인증을 지원하도록 항상 사용하도록 설정되어 있는지 확인합니다. 또한 클라이언트 애플리케이션은 핸드셰이크 단계에서 서버/클라이언트 ID(신뢰할 수 있는 인증 기관에서 발급한 서버의 인증서를 확인)를 확인하도록 설계되어야 합니다.

참고: API 게이트웨이와 같은 서비스는 TLS 상호 인증을 지원합니다.

AWS 구현 및 추가 컨텍스트:

  • AWS 인증서 관리자 인증서 고정을 .
  • 백 엔드 인증 SSL 인증서

GCP 지침: 대부분의 GCP 서비스는 기본적으로 TLS 인증을 지원합니다. 기본적으로 이를 지원하지 않거나 TLS 비활성화를 지원하는 서비스의 경우 항상 서버/클라이언트 인증을 지원하도록 사용하도록 설정되어 있는지 확인합니다. 또한 클라이언트 애플리케이션은 핸드셰이크 단계에서 서버/클라이언트 ID(신뢰할 수 있는 인증 기관에서 발급한 서버의 인증서를 확인)를 확인하도록 설계되어야 합니다.

참고: 클라우드 부하 분산과 같은 서비스는 TLS 상호 인증을 지원합니다.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-5: 애플리케이션 액세스에 SSO(Single Sign-On) 사용

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
12.5 IA-4, IA-2, IA-8 해당 없음(N/A)

보안 원칙: SSO(Single Sign-On)를 사용하여 클라우드 서비스 및 온-프레미스 환경에서 애플리케이션 및 데이터를 포함한 리소스에 인증하기 위한 사용자 환경을 간소화합니다.

Azure 지침: Azure AD SSO(Single Sign-On)를 통한 워크로드 애플리케이션 액세스(고객 연결) 액세스에 Azure AD를 사용하여 중복 계정의 필요성을 줄입니다. Azure AD는 AZURE 리소스(CLI, PowerShell, 포털 포함), 클라우드 애플리케이션 및 온-프레미스 애플리케이션에 대한 ID 및 액세스 관리를 제공합니다.

또한 Azure AD는 회사 사용자 ID와 같은 엔터프라이즈 ID뿐만 아니라 신뢰할 수 있는 타사 및 공용 사용자의 외부 사용자 ID에 대한 SSO도 지원합니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: AWS Cognito를 사용하여 SSO(Single Sign-On)를 통해 고객 대상 애플리케이션 워크로드에 대한 액세스를 관리하여 고객이 다양한 ID 제공업체에서 타사 ID를 연결할 수 있도록 합니다.

AWS 네이티브 리소스에 대한 SSO 액세스(AWS 콘솔 액세스 또는 서비스 관리 및 데이터 평면 수준 액세스 포함)의 경우 AWS Sigle Sign-On 사용하여 중복 계정의 필요성을 줄입니다.

또한 AWS SSO를 사용하면 회사 ID(예: Azure Active Directory의 ID)를 AWS ID와 연결하고 신뢰할 수 있는 타사 및 공용 사용자의 외부 사용자 ID를 연결할 수 있습니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: Google Cloud Identity를 사용하여 Google Cloud Identity Single Sign-On을 통해 고객 연결 워크로드 애플리케이션에 대한 액세스를 관리하여 중복 계정의 필요성을 줄입니다. Google Cloud Identity는 GCP(Google Cloud CLI, 콘솔 액세스를 비롯한 관리 평면), 클라우드 애플리케이션 및 온-프레미스 애플리케이션에 대한 ID 및 액세스 관리를 제공합니다.

Google Cloud Identity는 Azure AD 또는 Active Directory의 회사 사용자 ID와 같은 엔터프라이즈 ID뿐만 아니라 신뢰할 수 있는 타사 및 공용 사용자의 외부 사용자 ID에 대해서도 SSO를 지원합니다. GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-6: 강력한 인증 컨트롤 사용

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

보안 원칙: 리소스에 대한 모든 액세스에 대해 중앙 집중식 ID 및 인증 관리 시스템으로 강력한 인증 제어(강력한 암호 없는 인증 또는 다단계 인증)를 적용합니다. 암호 자격 증명만을 기반으로 하는 인증은 안전하지 않고 인기 있는 공격 방법을 지원하지 않으므로 레거시로 간주됩니다.

강력한 인증을 배포할 때 먼저 관리자 및 권한 있는 사용자를 구성하여 가장 높은 수준의 강력한 인증 방법을 보장한 다음, 모든 사용자에게 적절한 강력한 인증 정책을 신속하게 배포합니다.

참고: 레거시 애플리케이션 및 시나리오에 레거시 암호 기반 인증이 필요한 경우 복잡성 요구 사항과 같은 암호 보안 모범 사례를 준수해야 합니다.

Azure 지침: Azure AD는 암호 없는 방법과 MFA(다단계 인증)를 통해 강력한 인증 제어를 지원합니다.

  • 암호 없는 인증: 암호 없는 인증을 기본 인증 방법으로 사용합니다. 암호 없는 인증에는 비즈니스용 Windows Hello, Microsoft Authenticator 앱 전화 로그인 및 FIDO2 보안 키의 세 가지 옵션이 있습니다. 또한 고객은 스마트 카드와 같은 온-프레미스 인증 방법을 사용할 수 있습니다.
  • 다단계 인증: 로그인 조건 및 위험 요소에 따라 모든 사용자, 사용자 선택 또는 사용자별 수준에서 Azure MFA를 적용할 수 있습니다. Azure MFA를 사용하도록 설정하고 MFA 설정에 대한 Microsoft Defender for Cloud ID 및 액세스 관리 권장 사항을 따릅니다.

레거시 암호 기반 인증이 여전히 Azure AD 인증에 사용되는 경우 클라우드 전용 계정(Azure에서 직접 만든 사용자 계정)에 기본 기준 암호 정책이 있다는 점에 유의하세요. 하이브리드 계정(온-프레미스 Active Directory에서 온 사용자 계정)은 온-프레미스 암호 정책을 따릅니다.

기본 ID와 암호가 있을 수 있는 타사 애플리케이션 및 서비스의 경우 초기 서비스 설정 중에 사용하지 않도록 설정하거나 변경해야 합니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: AWS IAM은 MFA(다단계 인증)를 통해 강력한 인증 제어를 지원합니다. MFA는 정의된 조건에 따라 모든 사용자, 사용자 선택 또는 사용자별 수준에서 적용할 수 있습니다.

AWS ID와 함께 타사 디렉터리(예: Windows Active Directory)의 회사 계정을 사용하는 경우 해당 보안 지침에 따라 강력한 인증을 적용합니다. Azure AD를 사용하여 AWS 액세스를 관리하는 경우 이 컨트롤에 대한 Azure 지침을 참조하세요.

참고: 기본 ID와 암호가 있을 수 있는 타사 애플리케이션 및 AWS 서비스의 경우 초기 서비스 설정 중에 사용하지 않도록 설정하거나 변경해야 합니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: Google Cloud Identity는 MFA(다단계 인증)를 통해 강력한 인증 제어를 지원합니다. MFA는 정의된 조건에 따라 모든 사용자, 사용자 선택 또는 사용자별 수준에서 적용할 수 있습니다. 클라우드 ID(및 작업 영역) 슈퍼 관리자 계정을 보호하려면 보안을 극대화하기 위해 보안 키와 Google 고급 보호 프로그램을 사용하는 것이 좋습니다.

Google Cloud ID와 함께 타사 디렉터리(예: Windows Active Directory)의 회사 계정을 사용하는 경우 해당 보안 지침에 따라 강력한 인증을 적용합니다. Azure AD를 사용하여 Google Cloud 액세스를 관리하는 경우 이 컨트롤에 대한 Azure 지침을 참조하세요.

Identity-Aware 프록시를 사용하여 HTTPS에서 액세스하는 애플리케이션에 대한 중앙 권한 부여 계층을 설정하므로 네트워크 수준 방화벽을 사용하는 대신 애플리케이션 수준 액세스 제어 모델을 사용할 수 있습니다.

참고: 기본 ID와 암호가 있을 수 있는 타사 애플리케이션 및 GCP 서비스의 경우 초기 서비스 설정 중에 사용하지 않도록 설정하거나 변경해야 합니다.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-7: 조건에 따라 리소스 액세스 제한

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
3.3, 6.4, 13.5 교류-2, 교류-3, 교류-6 7.2

보안 원칙: 제로 트러스트 액세스 모델의 일부로 리소스에 대한 사용자 액세스를 허용하거나 거부하는 신뢰할 수 있는 신호의 유효성을 명시적으로 검사합니다. 유효성을 검사하는 신호에는 사용자 계정의 강력한 인증, 사용자 계정의 동작 분석, 디바이스 신뢰도, 사용자 또는 그룹 멤버 자격, 위치 등이 포함되어야 합니다.

Azure 지침: 특정 IP 범위(또는 디바이스)의 사용자 로그인이 MFA를 사용하도록 요구하는 등 사용자 정의 조건에 따라 보다 세부적인 액세스 제어에 Azure AD 조건부 액세스를 사용합니다. Azure AD 조건부 액세스를 사용하면 특정 조건에 따라 조직의 앱에 액세스 제어를 적용할 수 있습니다.

워크로드에서 Azure AD 조건부 액세스에 적용 가능한 조건 및 조건을 정의합니다. 다음과 같은 일반적인 사용 사례를 고려합니다.

  • 관리 역할을 가진 사용자에 대한 다단계 인증 필요
  • Azure 관리 작업에 다단계 인증 필요
  • 레거시 인증 프로토콜을 사용하려는 사용자의 로그인 차단
  • Azure AD Multi-Factor Authentication 등록을 위해 신뢰할 수 있는 위치 요구
  • 특정 위치에서의 액세스를 차단하거나 권한 부여하는 경우
  • 위험한 로그인 동작 차단
  • 특정 애플리케이션에 조직 관리 디바이스가 필요한 경우

참고: 로그인 빈도 및 영구 브라우저 세션과 같은 Azure AD 조건부 액세스 정책을 통해 세분화된 인증 세션 관리 컨트롤을 구현할 수도 있습니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: IAM 정책을 만들고 특정 IP 범위(또는 디바이스)의 사용자 로그인이 다단계 인증을 사용하도록 요구하는 등 사용자 정의 조건에 따라 보다 세부적인 액세스 제어에 대한 조건을 정의합니다. 조건 설정에는 논리뿐만 아니라 단일 또는 여러 조건이 포함될 수 있습니다.

정책은 ID 기반 정책, 리소스 기반 정책, 권한 경계, AWS 조직 SCP(서비스 제어 정책), ACL(액세스 제어 목록) 및 세션 정책 등 6가지 차원에서 정의할 수 있습니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: 특정 IP 범위(또는 디바이스)의 사용자 로그인이 다단계 인증을 사용하도록 요구하는 것과 같이 사용자 정의 조건에 따라 보다 세부적인 특성 기반 액세스 제어에 대한 IAM 조건을 만들고 정의합니다. 조건 설정에는 논리뿐만 아니라 단일 또는 여러 조건이 포함될 수 있습니다.

조건은 리소스 허용 정책의 역할 바인딩에 지정됩니다. 조건 특성은 요청된 리소스(예: 해당 형식 또는 이름) 또는 요청에 대한 세부 정보(예: 타임스탬프 또는 대상 IP 주소)를 기반으로 합니다.

GCP 구현 및 추가 컨텍스트:

  • IAM 조건 개요

고객 보안 관련자(자세한 정보):

IM-8: 자격 증명 및 비밀 노출 제한

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

보안 원칙: 애플리케이션 개발자가 자격 증명 및 비밀을 안전하게 처리해야 합니다.

  • 자격 증명 및 비밀을 코드 및 구성 파일에 포함하지 마세요.
  • 키 보관소 또는 보안 키 저장소 서비스를 사용하여 자격 증명과 비밀을 저장하다
  • 소스 코드에서 자격 증명을 검색합니다.

참고: 이는 종종 SDLC(보안 소프트웨어 개발 수명 주기) 및 DevOps 보안 프로세스를 통해 제어되고 적용됩니다.

Azure 지침: 관리 ID를 사용하는 것은 옵션이 아닌 경우 비밀 및 자격 증명을 코드 및 구성 파일에 포함하는 대신 Azure Key Vault와 같은 보안 위치에 저장해야 합니다.

코드 관리 플랫폼에 Azure DevOps 및 GitHub를 사용하는 경우:

  • Azure DevOps 자격 증명 스캐너를 구현하여 코드 내에서 자격 증명을 식별합니다.
  • GitHub의 경우 네이티브 비밀 검사 기능을 사용하여 코드 내에서 자격 증명 또는 다른 형태의 비밀을 식별합니다.

Azure Functions, Azure Apps 서비스 및 VM과 같은 클라이언트는 관리 ID를 사용하여 Azure Key Vault에 안전하게 액세스할 수 있습니다. 비밀 관리를 위해 Azure Key Vault 사용과 관련된 데이터 보호 컨트롤을 참조하세요.

참고: Azure Key Vault는 지원되는 서비스에 대해 자동 회전을 제공합니다. 자동으로 회전할 수 없는 비밀의 경우 수동으로 순환하고 더 이상 사용하지 않을 때 제거해야 합니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: 애플리케이션 액세스에 IAM 역할을 사용하는 것은 옵션이 아닌 경우 비밀 및 자격 증명을 코드 및 구성 파일에 포함하는 대신 AWS Secret Manager 또는 Systems Manager 매개 변수 저장소와 같은 보안 위치에 저장해야 합니다.

소스 코드에서 하드 코딩된 비밀을 검색할 수 있는 정적 코드 분석에 CodeGuru Reviewer를 사용합니다.

코드 관리 플랫폼에 Azure DevOps 및 GitHub를 사용하는 경우:

  • Azure DevOps 자격 증명 스캐너를 구현하여 코드 내에서 자격 증명을 식별합니다.
  • GitHub의 경우 네이티브 비밀 검사 기능을 사용하여 코드 내에서 자격 증명 또는 다른 형태의 비밀을 식별합니다.

참고: 비밀 관리자는 지원되는 서비스에 대한 자동 비밀 회전을 제공합니다. 자동으로 회전할 수 없는 비밀의 경우 수동으로 순환하고 더 이상 사용하지 않을 때 제거해야 합니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: Google이 관리하는 서비스 계정을 애플리케이션 액세스에 사용할 수 없을 때, 코드 및 구성 파일에 암호 및 자격 증명을 포함시키는 대신 Google Cloud의 Secret Manager와 같은 보안 위치에 저장해야 합니다.

Visual Studio Code와 같은 IDE(통합 개발 환경)의 Google 클라우드 코드 확장을 사용하여 Secret Manager에서 관리하는 비밀을 코드에 통합합니다.

코드 관리 플랫폼에 Azure DevOps 또는 GitHub를 사용하는 경우:

  • Azure DevOps 자격 증명 스캐너를 구현하여 코드 내에서 자격 증명을 식별합니다.
  • GitHub의 경우 네이티브 비밀 검사 기능을 사용하여 코드 내에서 자격 증명 또는 다른 형태의 비밀을 식별합니다.

참고: 비밀 관리자에 저장된 비밀에 대한 회전 일정을 모범 사례로 설정합니다.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):

IM-9: 기존 애플리케이션에 대한 사용자 액세스 보호

CIS 컨트롤 v8 ID NIST SP 800-53 r4 ID(들) PCI-DSS ID v3.2.1
6.7, 12.5 교류-2, 교류-3, 사우스캐롤라이나-11 해당 없음(N/A)

보안 원칙: 레거시 인증을 사용하는 온-프레미스 애플리케이션 또는 네이티브 클라우드 애플리케이션이 없는 하이브리드 환경에서는 CASB(클라우드 액세스 보안 브로커), 애플리케이션 프록시, SSO(Single Sign-On)와 같은 솔루션을 고려하여 이러한 애플리케이션에 대한 액세스를 제어하여 다음과 같은 이점을 얻을 수 있습니다.

  • 중앙 집중식 강력한 인증 적용
  • 위험한 최종 사용자 활동 모니터링 및 제어
  • 위험한 레거시 애플리케이션 활동 모니터링 및 수정
  • 중요한 데이터 전송 감지 및 방지

Azure 지침: 레거시 인증을 사용하여 온-프레미스 및 네이티브가 아닌 클라우드 애플리케이션을 다음과 같이 연결하여 보호합니다.

  • Azure AD 애플리케이션 프록시 및 헤더 기반 인증을 구성하여 원격 사용자에 대한 애플리케이션에 대한 SSO(Single Sign-On) 액세스를 허용하는 동시에 Azure AD 조건부 액세스를 사용하여 원격 사용자와 디바이스 모두의 신뢰성을 명시적으로 확인합니다. 필요한 경우 유사한 기능을 제공할 수 있는 타사 SDP(Software-Defined Perimeter) 솔루션을 사용합니다.
  • 클라우드 앱용 Microsoft Defender는 승인되지 않은 타사 SaaS 애플리케이션에 대한 사용자 액세스를 모니터링하고 차단하는 CASB(클라우드 액세스 보안 브로커) 서비스를 제공합니다.
  • 기존 타사 애플리케이션 전달 컨트롤러 및 네트워크.

참고: VPN은 일반적으로 레거시 애플리케이션에 액세스하는 데 사용되며 기본 액세스 제어 및 제한된 세션 모니터링만 있는 경우가 많습니다.

Azure 구현 및 추가 컨텍스트:

AWS 지침: Azure의 지침에 따라 레거시 인증을 사용하여 온-프레미스 및 비 네이티브 클라우드 애플리케이션을 다음과 같이 연결하여 보호합니다.

  • Azure AD 애플리케이션 프록시를 구성하고, 원격 사용자에 대한 애플리케이션에 대한 SSO(Single Sign-On) 액세스를 허용하는 헤더 기반 구성과 Azure AD 조건부 액세스를 사용하여 원격 사용자와 디바이스 모두의 신뢰성을 명시적으로 확인합니다. 필요한 경우 유사한 기능을 제공할 수 있는 타사 SDP(Software-Defined Perimeter) 솔루션을 사용합니다.
  • 클라우드 앱용 Microsoft Defender는 승인되지 않은 타사 SaaS 애플리케이션에 대한 사용자 액세스를 모니터링하고 차단하는 CASB(클라우드 액세스 보안 브로커) 서비스 역할을 합니다.
  • 기존 타사 애플리케이션 전달 컨트롤러 및 네트워크

참고: VPN은 일반적으로 레거시 애플리케이션에 액세스하는 데 사용되며 기본 액세스 제어 및 제한된 세션 모니터링만 있는 경우가 많습니다.

AWS 구현 및 추가 컨텍스트:

GCP 지침: Google Cloud Identity-Aware 프록시(IAP)를 사용하여 온-프레미스 애플리케이션을 포함하여 Google Cloud 외부의 HTTP 기반 애플리케이션에 대한 액세스를 관리합니다. IAP는 앱 엔진 표준 환경 내에서 서명된 헤더 또는 사용자 API를 사용하여 작동합니다. 필요한 경우 유사한 기능을 제공할 수 있는 타사 SDP(Software-Defined Perimeter) 솔루션을 사용합니다.

CASB(클라우드 액세스 보안 브로커) 서비스 역할을 하는 Cloud Apps용 Microsoft Defender를 사용하여 승인되지 않은 타사 SaaS 애플리케이션에 대한 사용자 액세스를 모니터링하고 차단하는 옵션도 있습니다.

참고: VPN은 일반적으로 레거시 애플리케이션에 액세스하는 데 사용되며 기본 액세스 제어 및 제한된 세션 모니터링만 있는 경우가 많습니다.

GCP 구현 및 추가 컨텍스트:

고객 보안 관련자(자세한 정보):