보안 제어: ID 관리

  • 아티클

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

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

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

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

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

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

참고: 기술적으로 실현 가능한 즉시 온-프레미스 Active Directory 기반 애플리케이션을 Azure AD로 마이그레이션해야 합니다. 이는 Azure AD 엔터프라이즈 디렉터리, 기업 간 구성 또는 기업 대 소비자 구성일 수 있습니다.

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

GCP 구현 및 추가 컨텍스트:

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

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

CIS Controls 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

보안 원칙: organization 클라우드 보안 사례에서 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 자격 증명 보고서를 사용하여 사용자 계정 및 자격 증명 상태 추적

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

AWS 구현 및 추가 컨텍스트:

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

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

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

GCP 구현 및 추가 컨텍스트:

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

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
해당 없음 AC-2, AC-3, IA-4, IA-5, IA-9 해당 없음

보안 원칙: 리소스에 액세스하고 코드를 실행하는 애플리케이션에 대한 사용자 계정을 만드는 대신 관리되는 애플리케이션 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 Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
해당 없음 IA-9 해당 없음

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

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

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

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

Azure 구현 및 추가 컨텍스트:

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

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

AWS 구현 및 추가 컨텍스트:

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

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

GCP 구현 및 추가 컨텍스트:

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

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
12.5 IA-4, IA-2, IA-8 해당 없음

보안 원칙: 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)를 통해 고객 지향 애플리케이션 워크로드에 대한 accces를 관리하여 고객이 다른 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 Controls 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 설정에 대한 클라우드 ID 및 액세스 관리 권장 사항에 대한 Microsoft Defender 따릅니다.

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 Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

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

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

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

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

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

Azure 구현 및 추가 컨텍스트:

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

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

AWS 구현 및 추가 컨텍스트:

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

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

GCP 구현 및 추가 컨텍스트:

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

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

CIS Controls 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의 비밀 관리자와 같은 보안 위치에 저장해야 합니다.

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

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

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

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

GCP 구현 및 추가 컨텍스트:

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

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 해당 없음

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

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

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

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

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

Azure 구현 및 추가 컨텍스트:

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

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

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

AWS 구현 및 추가 컨텍스트:

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

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

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

GCP 구현 및 추가 컨텍스트:

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