ID 및 액세스 보안 권장 사항

아티클
09/06/2024

이 문서에서는 클라우드용 Microsoft Defender 볼 수 있는 모든 ID 및 액세스 보안 권장 사항을 나열합니다.

사용자 환경에 표시되는 권장 사항은 보호 중인 리소스와 사용자 지정된 구성을 기반으로 합니다.

이러한 권장 사항에 대한 응답으로 수행할 수 있는 작업에 대해 알아보려면 클라우드용 Defender 권장 사항 수정을 참조하세요.

팁

권장 사항 설명에 관련 정책이 없다고 표시되는 경우 일반적으로 권장 사항은 다른 권장 사항에 따라 달라지기 때문입니다.

예를 들어 Endpoint Protection 상태 오류를 수정해야 하는 권장 사항은 엔드포인트 보호 솔루션이 설치되어 있는지 여부를 확인하는 권장 사항에 의존합니다(Endpoint Protection 솔루션을 설치해야 함). 기본 권장 사항에는 정책이 있습니다. 정책을 기본 권장 사항으로만 제한하면 정책 관리가 간소화됩니다.

Azure ID 및 액세스 권장 사항

구독에 최대 3명의 소유자를 지정해야 합니다.

설명: 손상된 소유자 계정의 위반 가능성을 줄이려면 소유자 계정 수를 최대 3개로 제한하는 것이 좋습니다(관련 정책: 구독에 대해 최대 3개의 소유자를 지정해야 합니다).

심각도: 높음

Azure Cosmos DB 계정에서 Azure Active Directory를 유일한 인증 방법으로 사용해야 함

설명: Azure 서비스에 인증하는 가장 좋은 방법은 RBAC(역할 기반 액세스 제어)를 사용하는 것입니다. RBAC를 사용하면 최소 권한 원칙을 유지할 수 있으며, 손상되었을 때 효과적인 대응 방법으로 권한을 취소하는 기능을 지원합니다. RBAC를 유일한 인증 방법으로 적용하도록 Azure Cosmos DB 계정을 구성할 수 있습니다. 적용이 구성되면 다른 모든 액세스 방법(기본/보조 키 및 액세스 토큰)이 거부됩니다. (관련 정책 없음)

심각도: 보통

Azure 리소스에 대한 소유자 권한이 있는 차단된 계정을 제거해야 함

설명: Active Directory에서 로그인이 차단된 계정은 Azure 리소스에서 제거해야 합니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책 없음)

심각도: 높음

Azure 리소스에 대한 읽기 및 쓰기 권한이 있는 차단된 계정을 제거해야 함

심각도: 높음

더 이상 사용되지 않는 계정을 구독에서 제거해야 합니다.

설명: 로그인이 차단된 사용자 계정은 구독에서 제거해야 합니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책: 사용되지 않는 계정은 구독에서 제거해야 합니다).

심각도: 높음

소유자 권한이 있는 사용되지 않는 계정은 구독에서 제거해야 합니다.

설명: 로그인이 차단된 사용자 계정은 구독에서 제거해야 합니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책: 소유자 권한이 있는 사용되지 않는 계정은 구독에서 제거해야 합니다).

심각도: 높음

Key Vault의 진단 로그를 사용하도록 설정해야 합니다.

설명: 로그를 사용하도록 설정하고 최대 1년 동안 유지합니다. 이렇게 하면 보안 인시던트가 발생하거나 네트워크가 손상된 경우 조사 목적으로 활동 내역을 다시 만들 수 있습니다. (관련 정책: Key Vault의 진단 로그를 사용하도록 설정해야 함).

심각도: 낮음

소유자 권한이 있는 외부 계정을 구독에서 제거해야 합니다.

설명: 도메인 이름(외부 계정)이 다른 소유자 권한이 있는 계정은 구독에서 제거해야 합니다. 이렇게 하면 모니터링되지 않는 액세스가 방지됩니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책: 소유자 권한이 있는 외부 계정은 구독에서 제거해야 합니다).

심각도: 높음

읽기 권한이 있는 외부 계정을 구독에서 제거해야 합니다.

설명: 도메인 이름(외부 계정)이 다른 읽기 권한이 있는 계정은 구독에서 제거해야 합니다. 이렇게 하면 모니터링되지 않는 액세스가 방지됩니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책: 읽기 권한이 있는 외부 계정은 구독에서 제거해야 합니다).

심각도: 높음

쓰기 권한이 있는 외부 계정을 구독에서 제거해야 합니다.

설명: 도메인 이름(외부 계정)이 다른 쓰기 권한이 있는 계정은 구독에서 제거해야 합니다. 이렇게 하면 모니터링되지 않는 액세스가 방지됩니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책: 쓰기 권한이 있는 외부 계정은 구독에서 제거해야 합니다).

심각도: 높음

Key Vault에서 방화벽을 사용하도록 설정해야 함

설명: 키 자격 증명 모음의 방화벽은 무단 트래픽이 키 자격 증명 모음에 도달하는 것을 방지하고 비밀에 대한 추가 보호 계층을 제공합니다. 방화벽을 사용하도록 설정하여 허용된 네트워크의 트래픽만 키 자격 증명 모음에 액세스할 수 있는지 확인합니다. (관련 정책: Key Vault에서 방화벽을 사용하도록 설정해야 함).

심각도: 보통

Azure 리소스에 대한 소유자 권한이 있는 게스트 계정을 제거해야 함

설명: Azure Active Directory 테넌트 외부에서 프로비전된 소유자 권한이 있는 계정(다른 도메인 이름)을 Azure 리소스에서 제거해야 합니다. 게스트 계정은 엔터프라이즈 테넌트 ID와 동일한 표준으로 관리되지 않습니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책 없음)

심각도: 높음

Azure 리소스에 대한 읽기 권한이 있는 게스트 계정을 제거해야 함

설명: Azure Active Directory 테넌트 외부에서 프로비전된 읽기 권한이 있는 계정(다른 도메인 이름)을 Azure 리소스에서 제거해야 합니다. 게스트 계정은 엔터프라이즈 테넌트 ID와 동일한 표준으로 관리되지 않습니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책 없음)

심각도: 높음

Azure 리소스에 대한 쓰기 권한이 있는 게스트 계정을 제거해야 함

설명: Azure Active Directory 테넌트 외부에서 프로비전된 쓰기 권한이 있는 계정(다른 도메인 이름)은 Azure 리소스에서 제거해야 합니다. 게스트 계정은 엔터프라이즈 테넌트 ID와 동일한 표준으로 관리되지 않습니다. 이러한 계정은 눈치 채지 못한 채 데이터에 액세스하는 방법을 찾는 공격자의 대상이 될 수 있습니다. (관련 정책 없음)

심각도: 높음

Key Vault 키에는 만료 날짜가 있어야 함

설명: 암호화 키에는 정의된 만료 날짜가 있어야 하며 영구적이지 않아야 합니다. 영구적으로 유효한 키는 잠재적인 공격자에게 키를 손상시킬 수 있는 시간을 더 많이 제공합니다. 암호화 키에 만료 날짜를 설정하는 것이 좋습니다. (관련 정책: Key Vault 키에는 만료 날짜가 있어야 합니다).

심각도: 높음

Key Vault 비밀에는 만료 날짜가 있어야 함

설명: 비밀에는 정의된 만료 날짜가 있어야 하며 영구적이지 않아야 합니다. 영구적으로 유효한 비밀은 잠재적인 공격자에게 비밀을 손상시킬 수 있는 시간을 더 많이 제공합니다. 비밀에 만료 날짜를 설정하는 것이 좋습니다. (관련 정책: Key Vault 비밀에는 만료 날짜가 있어야 합니다).

심각도: 높음

키 자격 증명 모음에 제거 방지를 사용하도록 설정해야 함

설명: 키 자격 증명 모음을 악의적으로 삭제하면 데이터가 영구적으로 손실됩니다. 조직의 악의적인 내부자가 잠재적으로 키 자격 증명 모음을 삭제하고 제거할 수 있습니다. 제거 보호는 일시 삭제된 키 자격 증명 모음에 대해 필수 보존 기간을 적용하여 내부자 공격으로부터 보호합니다. 일시 삭제 보존 기간 동안에는 조직 또는 Microsoft 내부의 어느 누구도 키 자격 증명 모음을 제거할 수 없습니다. (관련 정책: 키 자격 증명 모음은 제거 보호를 사용하도록 설정해야 함).

심각도: 보통

키 자격 증명 모음에 일시 삭제를 사용하도록 설정해야 함

설명: 일시 삭제를 사용하지 않고 키 자격 증명 모음을 삭제하면 키 자격 증명 모음에 저장된 모든 비밀, 키 및 인증서가 영구적으로 삭제됩니다. 키 자격 증명 모음을 실수로 삭제하면 데이터가 영구적으로 손실될 수 있습니다. 일시 삭제를 사용하면 실수로 삭제된 키 자격 증명 모음을 구성 가능한 보존 기간 동안 복구할 수 있습니다. (관련 정책: 키 자격 증명 모음은 일시 삭제를 사용하도록 설정해야 함).

심각도: 높음

Key Vault용 Microsoft Defender를 사용하도록 설정해야 함

설명: 클라우드용 Microsoft Defender 추가 보안 인텔리전스 계층을 제공하는 Key Vault용 Microsoft Defender를 포함합니다. Microsoft Defender for Key Vault는 Key Vault 계정에 액세스하거나 이를 악용하려는 비정상적이고 잠재적으로 유해한 시도를 탐지합니다.

이 플랜의 보호는 Defender 계획 페이지에 표시된 대로 요금이 청구됩니다. 이 구독에 키 자격 증명 모음이 없으면 요금이 발생하지 않습니다. 나중에 이 구독에 키 자격 증명 모음을 만들면 자동으로 보호되고 요금이 청구됩니다. 지역별 가격 책정 세부 정보에 대해 알아봅니다. 키 자격 증명 모음용 Microsoft Defender 소개에서 자세히 알아보세요. (관련 정책: Key Vault용 Azure Defender를 사용하도록 설정해야 함).

심각도: 높음

Azure 구독에서 비활성 ID의 사용 권한을 취소해야 합니다.

설명: 클라우드용 Microsoft Defender 지난 45일 동안 Azure 구독 내의 리소스에 대해 아무 작업도 수행하지 않은 ID를 발견했습니다. 클라우드 환경의 공격 노출 영역을 줄이기 위해 비활성 ID의 사용 권한을 취소하는 것이 좋습니다.

심각도: 보통

Key Vault에 대한 프라이빗 엔드포인트를 구성해야 합니다.

설명: 프라이빗 링크는 공용 인터넷을 통해 트래픽을 보내지 않고도 Key Vault를 Azure 리소스에 연결하는 방법을 제공합니다. 프라이빗 링크는 데이터 반출에 대한 심층 방어 기능을 제공합니다. (관련 정책: Key Vault에 대해 프라이빗 엔드포인트를 구성해야 함).

심각도: 보통

스토리지 계정 공용 액세스를 허용하지 않아야 합니다.

설명: Azure Storage의 컨테이너 및 Blob에 대한 익명 공용 읽기 액세스는 데이터를 공유하는 편리한 방법이지만 보안 위험을 초래할 수 있습니다. 원치 않는 익명 액세스로 인해 발생하는 데이터 위반을 방지하기 위해 Microsoft는 시나리오에 필요한 경우가 아니면 스토리지 계정에 대한 공개 액세스를 방지하는 것이 좋습니다 (관련 정책: 스토리지 계정 공용 액세스를 허용하지 않아야 함).

심각도: 보통

구독에 둘 이상의 소유자가 할당되어야 합니다.

설명: 관리자 액세스 중복성을 갖도록 둘 이상의 구독 소유자를 지정합니다. (관련 정책: 구독에 할당된 소유자가 두 개 이상 있어야 합니다).

심각도: 높음

Azure Key Vault에 저장된 인증서의 유효 기간은 12개월을 초과하지 않아야 합니다.

설명: 인증서에 12개월을 초과하는 유효 기간이 없는지 확인합니다. (관련 정책: 인증서에는 지정된 최대 유효 기간이 있어야 합니다).

심각도: 보통

Azure 오버프로비전된 ID에는 필요한 권한만 있어야 합니다(미리 보기).

설명: 과도하게 프로비전된 ID 또는 권한 있는 ID를 통해 부여된 많은 권한을 사용하지 않습니다. 실수로 또는 악의적인 권한 오용의 위험을 줄이기 위해 이러한 ID의 권한을 정기적으로 적절한 크기로 조정합니다. 이 작업은 보안 인시던트 동안 잠재적인 폭발 반경을 줄입니다.

심각도: 보통

권한 있는 역할은 구독 및 리소스 그룹 수준에서 영구 액세스 권한이 없어야 함

설명: 클라우드용 Microsoft Defender 지난 45일 동안 Azure 구독 내의 리소스에 대해 아무 작업도 수행하지 않은 ID를 발견했습니다. 클라우드 환경의 공격 노출 영역을 줄이기 위해 비활성 ID의 사용 권한을 취소하는 것이 좋습니다.

심각도: 높음

서비스 주체에는 구독 및 리소스 그룹 수준에서 관리 역할을 할당하면 안 됨

설명: 리소스 그룹 또는 구독 수준에서 권한 있는 역할로 할당된 식별된 서비스 주체를 클라우드용 Defender. 권한 있는 관리자 역할은 소유자, 기여자 또는 사용자 액세스 관리자와 같은 리소스에서 중요한 작업을 수행할 수 있는 역할입니다. 서비스 주체는 Azure 리소스를 효율적이고 안전하게 관리하는 데 중요한 역할을 하므로 사용자 개입이 필요하지 않습니다. 최소 권한의 원칙을 따르고 지정된 서비스 주체가 업무를 수행하는 데 필요한 최소 액세스 수준만 부여하는 것이 중요합니다. 관리자 및 권한 있는 액세스는 해커의 주요 대상입니다. 권한 있는 관리자 역할 할당을 사용하는 경우 모범 사례는 Azure RBAC에 대한 모범 사례를 참조하세요. Azure RBAC에 대한 모범 사례입니다. Azure RBAC에서 사용 가능한 역할 목록은 Azure의 기본 제공 역할을 참조 하세요.

심각도: 높음

AWS ID 및 액세스 권장 사항

Amazon Elasticsearch Service 도메인은 VPC에 있어야 합니다.

설명: VPC는 공용 엔드포인트가 있는 도메인을 포함할 수 없습니다. 이는 공용 연결 가능성을 결정하기 위해 VPC 서브넷 라우팅 구성을 평가하지 않습니다.

심각도: 높음

버킷 정책의 다른 AWS 계정에 부여된 Amazon S3 권한은 제한해야 합니다.

설명: 최소 권한 액세스를 구현하는 것은 보안 위험과 오류 또는 악의적인 의도의 영향을 줄이는 데 기본 사항입니다. S3 버킷 정책이 외부 계정의 액세스를 허용하는 경우 내부자 위협 또는 공격자에 의해 데이터가 반출될 수 있습니다. 'blacklistedactionpatterns' 매개 변수를 사용하면 S3 버킷 규칙을 평가할 수 있습니다. 매개 변수는 'blacklistedactionpatterns' 목록에 포함되지 않은 작업 패턴에 대한 외부 계정에 대한 액세스 권한을 부여합니다.

심각도: 높음

"루트" 계정을 사용하지 않습니다.

설명: "루트" 계정은 AWS 계정의 모든 리소스에 무제한으로 액세스할 수 있습니다. 이 계정을 사용하지 않는 것이 좋습니다. "루트" 계정은 가장 권한이 많은 AWS 계정입니다. 이 계정의 사용을 최소화하고 액세스 관리에 최소 권한 원칙을 채택하면 높은 권한의 자격 증명이 우발적으로 변경되거나 의도치 않게 공개될 위험이 줄어듭니다.

심각도: 높음

AWS KMS 키를 실수로 삭제해서는 안 됩니다.

설명: 이 컨트롤은 KMS 키를 삭제할 예정인지 여부를 확인합니다. KMS 키가 삭제되도록 예약된 경우 이 컨트롤은 검사에 불합격합니다. 삭제된 후에는 KMS 키를 복구할 수 없습니다. KMS 키를 삭제하면 KMS 키로 암호화된 데이터도 영구적으로 복구할 수 없습니다. 삭제하도록 예약된 KMS 키에서 의미 있는 데이터가 암호화된 경우 의도적으로 암호화 삭제를 수행하지 않는 한 데이터를 암호 해독하거나 새 KMS 키로 데이터를 다시 암호화하는 것이 좋습니다. KMS 키 삭제가 예약되면 실수로 예약된 경우 삭제를 취소할 수 있도록 필수 대기 기간이 적용됩니다. 기본 대기 기간은 30일이지만 KMS 키를 삭제하도록 예약된 경우 최대 7일로 줄일 수 있습니다. 대기 기간 동안 예약된 삭제를 취소할 수 있으며 KMS 키는 삭제되지 않습니다. KMS 키 삭제에 대한 자세한 내용은 AWS 키 관리 서비스 개발자 가이드에서 KMS 키 삭제를 참조하세요.

심각도: 높음

AWS 오버프로비전된 ID에는 필요한 권한만 있어야 합니다(미리 보기).

설명: 과도하게 프로비전된 활성 ID는 사용하지 않은 권한에 액세스할 수 있는 ID입니다. 과도하게 프로비전된 활성 ID, 특히 작업 및 책임을 정의한 비인간 계정의 경우 사용자, 키 또는 리소스가 손상될 경우 폭발 반경을 늘릴 수 있습니다. 불필요한 권한을 제거하고 최소 권한 권한을 얻기 위해 검토 프로세스를 설정합니다.

심각도: 보통

AWS WAF 클래식 글로벌 웹 ACL 로깅을 사용하도록 설정해야 합니다.

설명: 이 컨트롤은 AWS WAF 글로벌 Web ACL에 대해 로깅을 사용할 수 있는지 여부를 확인합니다. 웹 ACL에 로깅을 사용하도록 설정하지 않으면 이 컨트롤이 실패합니다. 로깅은 AWS WAF의 안정성, 가용성 및 성능을 전 세계적으로 유지하는 데 중요합니다. 많은 조직에서 비즈니스 및 규정 준수 요구 사항이며 애플리케이션 동작 문제를 해결할 수 있습니다. 또한 AWS WAF에 연결된 웹 ACL에서 분석하는 트래픽에 대한 자세한 정보를 제공합니다.

심각도: 보통

CloudFront 배포에서는 기본 루트 개체를 구성해야 합니다.

설명: 이 컨트롤은 Amazon CloudFront 배포판이 기본 루트 개체인 특정 개체를 반환하도록 구성되어 있는지 여부를 확인합니다. CloudFront 배포에 기본 루트 개체가 구성되지 않은 경우 컨트롤이 실패합니다. 사용자가 배포판의 개체 대신 배포판 루트 URL을 요청할 수도 있습니다. 이 경우 기본 루트 개체를 지정하면 웹 배포 콘텐츠가 노출되는 것을 방지할 수 있습니다.

심각도: 높음

CloudFront 배포에서는 원본 액세스 ID를 사용하도록 설정해야 합니다.

설명: 이 컨트롤은 Amazon S3 Origin 형식의 Amazon CloudFront 배포에 OAI(원본 액세스 ID)가 구성되어 있는지 여부를 확인합니다. OAI가 구성되지 않은 경우 컨트롤이 실패합니다. CloudFront OAI는 사용자가 S3 버킷 콘텐츠에 직접 액세스하는 것을 방지합니다. S3 버킷에 직접 액세스하는 사용자는 CloudFront 배포 및 기본 S3 버킷 콘텐츠에 적용되는 모든 권한을 효과적으로 바이패스합니다.

심각도: 보통

CloudTrail 로그 파일 유효성 검사를 사용하도록 설정해야 합니다.

설명: CloudTrail 로그의 추가 무결성 검사를 보장하려면 모든 CloudTrails에서 파일 유효성 검사를 사용하도록 설정하는 것이 좋습니다.

심각도: 낮음

CloudTrail을 사용하도록 설정해야 합니다.

설명: AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 제공하는 웹 서비스입니다. 모든 서비스가 모든 API 및 이벤트에 대해 기본적으로 로깅을 사용하는 것은 아닙니다. CloudTrail 이외의 다른 감사 내역을 추가로 구현하고 CloudTrail 지원 서비스 및 통합에서 각 서비스에 대한 설명서를 검토해야 합니다.

심각도: 높음

CloudTrail 추적을 CloudWatch Logs와 통합해야 합니다.

설명: 장기 분석을 위해 지정된 S3 버킷 내에서 CloudTrail 로그를 캡처하는 것 외에도 CloudTrail에서 CloudWatch 로그로 로그를 보내도록 구성하여 실시간 분석을 수행할 수 있습니다. 계정의 모든 영역에서 활성화된 추적의 경우 CloudTrail은 해당 영역의 로그 파일을 CloudWatch 로그 그룹으로 보냅니다. CloudTrail 로그를 CloudWatch Logs로 전송하여 AWS 계정 작업이 캡처 및 모니터링되고 적절하게 경고를 보내도록 하는 것이 좋습니다. CloudTrail 로그를 CloudWatch Logs로 보내면 사용자, API, 리소스 및 IP 주소를 기반으로 실시간 및 기록 작업 로깅이 용이해지고 비정상적이거나 민감한 계정 작업에 대한 경고 및 알림을 설정할 수 있습니다.

심각도: 낮음

데이터베이스 로깅을 사용하도록 설정해야 합니다.

설명: 이 컨트롤은 Amazon RDS의 다음 로그가 사용하도록 설정되어 CloudWatch 로그로 전송되는지 여부를 확인합니다.

Oracle: (경고, 감사, 추적, 수신기)
PostgreSQL: (Postgresql, 업그레이드)
MySQL: (감사, 오류, 일반, SlowQuery)
MariaDB: (감사, 오류, 일반, SlowQuery)
SQL Server: (오류, 에이전트)
오로라: (감사, 오류, 일반, SlowQuery)
Aurora-MySQL: (감사, 오류, 일반, SlowQuery)
Aurora-PostgreSQL: (Postgresql, Upgrade). RDS 데이터베이스에서는 관련 로그를 사용하도록 설정해야 합니다. 데이터베이스 로깅은 RDS에 대해 수행된 요청의 자세한 레코드를 제공합니다. 데이터베이스 로그는 보안 및 액세스 감사에 도움이 되고 가용성 문제를 진단하는 데 도움이 될 수 있습니다.

심각도: 보통

Amazon Sage Maker Notebook 인스턴스에 대한 직접 인터넷 액세스 사용 안 함

설명: Sage Maker Notebook 인스턴스에 대해 직접 인터넷 액세스를 사용하지 않도록 설정해야 합니다. 이렇게 하면 Notebook 인스턴스에 'DirectInternetAccess' 필드를 사용하지 않도록 설정되었는지 확인됩니다. VPC를 사용하여 인스턴스를 구성해야 하며 VPC를 통한 액세스를 사용하지 않는 것이 기본 설정이어야 합니다. 인터넷 액세스를 사용하여 Notebook에서 모델을 학습하거나 호스트할 수 있도록 하려면 VPC에 NAT 게이트웨이가 있고 보안 그룹에서 아웃바운드 연결을 허용해야 합니다. Sage Maker 구성에 대한 액세스가 권한 있는 사용자로만 제한되는지 확인하고 사용자의 IAM 권한을 제한하여 Sage Maker 설정 및 리소스를 수정합니다.

심각도: 높음

콘솔 암호가 있는 모든 IAM 사용자의 초기 사용자 설정 중에는 액세스 키를 설정하면 안 됩니다.

설명: AWS 콘솔은 사용하도록 설정할 액세스 키를 만들기 위한 확인란의 기본값을 지정합니다. 이로 인해 많은 액세스 키가 불필요하게 생성됩니다. 불필요한 자격 증명 외에도 이러한 키를 감사하고 회전할 때 불필요한 관리 작업도 생성합니다. 프로필이 생성된 후 사용자가 추가 단계를 수행하도록 요구하면 액세스 키가 작업에 필요하고 [b]가 조직에 있는 어딘가에서 사용 중일 수 있는 계정에 액세스 키가 설정되면 액세스 키가 필요하다는 의도를 더 강력하게 나타낼 수 있습니다.

심각도: 보통

AWS 지원을 통해 인시던트를 관리하기 위한 지원 역할을 만들었는지 확인해야 합니다.

설명: AWS는 인시던트 알림 및 대응뿐만 아니라 기술 지원 및 고객 서비스에 사용할 수 있는 지원 센터를 제공합니다. 권한이 있는 사용자가 AWS 지원을 통해 인시던트를 관리할 수 있는 IAM 역할을 만드세요. 액세스 제어에 대한 최소 권한을 구현하는 경우 IAM 역할에는 AWS 지원으로 인시던트를 관리하기 위해 지원 센터 액세스를 허용하는 적절한 IAM 정책이 필요합니다.

심각도: 낮음

90일 이하의 주기로 액세스 키를 회전해야 합니다.

설명: 액세스 키는 AWS에서 만드는 프로그래밍 방식 요청에 서명하는 데 사용되는 액세스 키 ID 및 비밀 액세스 키로 구성됩니다. AWS 사용자는 AWS CLI(AWS 명령줄 인터페이스), Windows PowerShell용 도구, AWS SDK에서 프로그래밍 방식으로 AWS를 호출하거나 개별 AWS 서비스에 대한 API를 사용하여 직접 HTTP를 호출을 하려면 자체 액세스 키가 필요합니다. 모든 액세스 키를 정기적으로 회전하는 것이 좋습니다. 액세스 키를 회전하면 손상된 계정 또는 종료된 계정과 연결된 액세스 키를 사용할 수 있는 기회가 줄어듭니다. 데이터 손실, 금이 또는 도난되었을 수 있는 이전 키를 사용하여 데이터에 액세스할 수 없도록 액세스 키를 회전해야 합니다.

심각도: 보통

모든 지역에서 AWS Config를 사용해야 합니다.

설명: AWS 구성은 계정 내에서 지원되는 AWS 리소스의 구성 관리를 수행하고 로그 파일을 제공하는 웹 서비스입니다. 기록된 정보에는 구성 항목(AWS 리소스), 구성 항목 간의 관계(AWS 리소스), 리소스 간의 구성 변경이 포함됩니다. 모든 지역에서 AWS 구성을 사용하도록 설정하는 것이 좋습니다.

AWS Config에서 캡처한 AWS 구성 항목 기록을 사용하면 보안 분석, 리소스 변경 내용 추적 및 규정 준수 감사가 가능합니다.

심각도: 보통

모든 지역에서 CloudTrail을 사용해야 합니다.

설명: AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 제공하는 웹 서비스입니다. 기록된 정보에는 API 호출자 ID, API 호출 시간, API 호출자의 원본 IP 주소, 요청 매개 변수 및 AWS 서비스에서 반환된 응답 요소가 포함됩니다. CloudTrail은 관리 콘솔, SDK, 명령줄 도구 및 고급 AWS 서비스(예: CloudFormation)를 통해 수행된 API 호출을 포함하여 계정에 대한 AWS API 호출 기록을 제공합니다. CloudTrail에서 생성된 AWS API 호출 기록을 통해 보안 분석, 리소스 변경 내용 추적 및 규정 준수 감사를 수행할 수 있습니다. 또한:

다중 지역 내역이 있는지 확인하면 사용되지 않는 지역에서 발생하는 예기치 않은 활동이 검색됩니다.
다중 지역 내역이 있는지 확인하면 AWS 글로벌 서비스에서 생성된 이벤트의 기록을 캡처하기 위해 기본적으로 추적에 대해 "글로벌 서비스 로깅"이 사용하도록 설정되어 있는지 확인합니다.
다중 지역 추적의 경우 모든 유형의 읽기/쓰기에 대해 관리 이벤트가 구성되어 있는지 확인하면 AWS 계정의 모든 리소스에서 수행되는 관리 작업을 기록할 수 있습니다.

심각도: 높음

90일 이상 사용되지 않은 자격 증명은 사용하지 않습니다.

설명: AWS IAM 사용자는 암호 또는 액세스 키와 같은 다양한 유형의 자격 증명을 사용하여 AWS 리소스에 액세스할 수 있습니다. 90일 이상 사용되지 않은 모든 자격 증명을 제거하거나 비활성화하는 것이 좋습니다. 불필요한 자격 증명을 사용하지 않도록 설정하거나 제거하면 손상되거나 중단된 계정과 연결된 자격 증명을 사용할 수 있는 기회가 줄어듭니다.

심각도: 보통

IAM 암호 정책에서 암호가 90일 이내에 만료되도록 합니다.

설명: IAM 암호 정책은 지정된 일 수 후에 암호를 회전하거나 만료하도록 요구할 수 있습니다. 암호 정책은 90일 이내에 암호를 만료하는 것이 좋습니다. 암호 수명을 줄이면 무차별 암호 대입 로그인 시도에 대한 계정 복원력이 향상됩니다. 또한 다음 시나리오에서는 주기적으로 암호를 변경하도록 요구하는 것이 좋습니다.

암호를 도난당하거나 손상될 수 있습니다. 이 문제는 시스템 손상, 소프트웨어 취약성 또는 내부 위협으로 인해 발생할 수 있습니다.
특정 회사 및 정부 웹 필터 또는 프록시 서버는 암호화된 경우에도 트래픽을 가로채고 기록할 수 있습니다.
많은 사람들이 회사, 전자 메일 및 개인과 같은 많은 시스템에 동일한 암호를 사용합니다.
손상된 최종 사용자 워크스테이션에는 키 입력 로거가 있을 수 있습니다.

심각도: 낮음

IAM 암호 정책에서 암호를 재사용하지 못하게 합니다.

설명: IAM 암호 정책은 동일한 사용자가 지정된 암호를 다시 사용하는 것을 방지할 수 있습니다. 암호 정책은 암호 재사용을 방지하는 것이 좋습니다. 암호를 다시 사용하지 못하게 막으면 무차별 암호 대입 로그인 시도에 대한 계정 복원력이 향상됩니다.

심각도: 낮음

IAM 암호 정책에서 소문자를 하나 이상 사용하도록 요구합니다.

설명: 암호 정책은 부분적으로 암호 복잡성 요구 사항을 적용하는 데 사용됩니다. IAM 암호 정책을 사용하여 암호가 서로 다른 문자 집합으로 구성되도록 할 수 있습니다. 암호 정책에는 하나 이상의 소문자가 필요한 것이 좋습니다. 암호 복잡성 정책을 설정하면 무차별 암호 대입 시도에 대한 계정 복원력이 향상됩니다.

심각도: 보통

IAM 암호 정책에서 숫자를 하나 이상 사용하도록 요구합니다.

설명: 암호 정책은 부분적으로 암호 복잡성 요구 사항을 적용하는 데 사용됩니다. IAM 암호 정책을 사용하여 암호가 서로 다른 문자 집합으로 구성되도록 할 수 있습니다. 암호 정책에는 하나 이상의 숫자가 필요한 것이 좋습니다. 암호 복잡성 정책을 설정하면 무차별 암호 대입 시도에 대한 계정 복원력이 향상됩니다.

심각도: 보통

IAM 암호 정책에서 기호를 하나 이상 사용하도록 요구합니다.

설명: 암호 정책은 부분적으로 암호 복잡성 요구 사항을 적용하는 데 사용됩니다. IAM 암호 정책을 사용하여 암호가 서로 다른 문자 집합으로 구성되도록 할 수 있습니다. 암호 정책에는 하나 이상의 기호가 필요한 것이 좋습니다. 암호 복잡성 정책을 설정하면 무차별 암호 대입 시도에 대한 계정 복원력이 향상됩니다.

심각도: 보통

IAM 암호 정책에서 대문자를 하나 이상 사용하도록 요구합니다.

설명: 암호 정책은 부분적으로 암호 복잡성 요구 사항을 적용하는 데 사용됩니다. IAM 암호 정책을 사용하여 암호가 서로 다른 문자 집합으로 구성되도록 할 수 있습니다. 암호 정책에는 하나 이상의 대문자가 필요한 것이 좋습니다. 암호 복잡성 정책을 설정하면 무차별 암호 대입 시도에 대한 계정 복원력이 향상됩니다.

심각도: 보통

IAM 암호 정책에서 14자 이상의 최소 길이를 요구합니다.

설명: 암호 정책은 부분적으로 암호 복잡성 요구 사항을 적용하는 데 사용됩니다. IAM 암호 정책을 사용하여 지정된 길이 이상의 암호만 허용할 수 있습니다. 암호 정책에는 최소 암호 길이 '14'가 필요한 것이 좋습니다. 암호 복잡성 정책을 설정하면 무차별 암호 대입 시도에 대한 계정 복원력이 향상됩니다.

심각도: 보통

콘솔 암호가 있는 모든 IAM 사용자에 대해 MFA(다단계 인증)가 사용하도록 설정되어 있는지 확인합니다.

설명: MFA(다단계 인증)는 사용자 이름 및 암호 위에 추가 보호 계층을 추가합니다. MFA를 사용하도록 설정하면 사용자가 AWS 웹 사이트에 로그인하면 AWS MFA 디바이스의 인증 코드뿐만 아니라 사용자 이름 및 암호를 묻는 메시지가 표시됩니다. 콘솔 암호가 있는 모든 계정에 대해 MFA를 사용하도록 설정하는 것이 좋습니다. MFA를 사용하면 인증 담당자가 시간에 민감한 키를 내보내고 자격 증명을 알고 있는 디바이스를 소유해야 하므로 콘솔 액세스에 대한 보안이 강화됩니다.

심각도: 보통

GuardDuty를 사용하도록 설정해야 합니다.

설명: 침입에 대한 추가 보호를 제공하려면 AWS 계정 및 지역에서 GuardDuty를 사용하도록 설정해야 합니다.

GuardDuty는 모든 환경에 대한 완전한 솔루션이 아닐 수 있습니다.

심각도: 보통

"루트" 계정에 하드웨어 MFA를 사용해야 합니다.

설명: 루트 계정은 계정에서 가장 권한이 있는 사용자입니다. MFA는 사용자 이름 및 암호 위에 보호 계층을 추가합니다. MFA를 사용하면 사용자가 AWS 웹 사이트에 로그인할 때 사용자 이름 및 암호와 AWS MFA 디바이스의 인증 코드를 입력해야 합니다. 수준 2의 경우 하드웨어 MFA를 사용하여 루트 계정을 보호하는 것이 좋습니다. 하드웨어 MFA의 공격 표면은 가상 MFA보다 작습니다. 예를 들어 하드웨어 MFA는 가상 MFA가 상주하는 모바일 스마트폰에 의한 공격 표면이 없습니다. MFA용 하드웨어를 여러 계정에 사용하는 경우 로지스틱 디바이스 관리 문제가 발생할 수 있습니다. 이 경우 최상위 보안 계정에 선택적으로 2레벨 권장 사항을 구현하는 것이 좋습니다. 나머지 계정에는 1레벨 권장 사항을 적용하면 됩니다.

심각도: 낮음

RDS 클러스터에 대해 IAM 인증을 구성해야 합니다.

설명: 이 컨트롤은 RDS DB 클러스터에 IAM 데이터베이스 인증이 사용하도록 설정되어 있는지 여부를 확인합니다. IAM 데이터베이스 인증을 사용하면 암호 없이 데이터베이스 인스턴스에 인증할 수 있습니다. 인증에는 인증 토큰이 사용됩니다. 데이터베이스와 주고 받은 네트워크 트래픽은 SSL을 사용하여 암호화됩니다. 자세한 내용은 Amazon Aurora 사용자 가이드의 IAM 데이터베이스 인증을 참조하세요.

심각도: 보통

RDS 인스턴스에 대해 IAM 인증을 구성해야 합니다.

설명: 이 컨트롤은 RDS DB 인스턴스에 IAM 데이터베이스 인증이 사용하도록 설정되어 있는지 여부를 확인합니다. IAM 데이터베이스 인증을 사용하면 암호 대신 인증 토큰을 사용하여 데이터베이스 인스턴스에 인증할 수 있습니다. 데이터베이스와 주고 받은 네트워크 트래픽은 SSL을 사용하여 암호화됩니다. 자세한 내용은 Amazon Aurora 사용자 가이드의 IAM 데이터베이스 인증을 참조하세요.

심각도: 보통

IAM 고객 관리형 정책은 모든 KMS 키에서 암호 해독 작업을 허용하지 않아야 합니다.

설명: IAM 고객 관리 정책의 기본 버전에서 보안 주체가 모든 리소스에서 AWS KMS 암호 해독 작업을 사용할 수 있는지 여부를 확인합니다. 이 컨트롤은 자동화된 추론 엔진인 Zelkova를 사용하여 AWS 계정에서 비밀에 대한 광범위한 액세스 권한을 부여할 수 있는 정책의 유효성을 검사하고 경고합니다. 모든 KMS 키에서 "kms: Decrypt" 또는 "kms: ReEncryptFrom" 작업이 허용되는 경우 이 컨트롤이 실패합니다. 이 컨트롤은 연결된 고객 관리형 정책과 연결되지 않은 고객 관리형 정책을 모두 평가합니다. 인라인 정책 또는 AWS 관리 정책을 확인하지 않습니다. AWS KMS를 사용하면 KMS 키를 사용하여 암호화된 데이터에 대한 액세스 권한을 얻을 수 있는 사용자를 제어할 수 있습니다. IAM 정책은 ID(사용자, 그룹 또는 역할)가 어떤 리소스에서 어떤 작업을 수행할 수 있는지 정의합니다. AWS 보안 모범 사례에 따라 최소 권한을 허용하는 것이 좋습니다. 즉, 작업을 수행하는 데 필요한 키에 대한 "kms:Decrypt" 또는 "kms:ReEncryptFrom" 권한만 ID에 부여해야 합니다. 그렇지 않으면 사용자가 데이터에 적합하지 않은 키를 사용할 수 있습니다. 모든 키에 대한 권한을 부여하지 말고, 사용자가 암호화된 데이터에 액세스하는 데 필요한 최소 키 세트를 결정합니다. 그런 다음, 사용자가 해당 키만 사용할 수 있도록 정책을 디자인합니다. 예를 들어 모든 KMS 키에 대해 "kms: 암호 해독" 권한을 허용하지 않습니다. 대신 계정의 특정 지역의 키에 대해서만 "kms: 암호 해독"을 허용합니다. 최소 권한 원칙을 채택하면 의도하지 않은 데이터 공개 위험을 줄일 수 있습니다.

심각도: 보통

사용자가 만든 IAM 고객 관리 정책은 서비스에 대한 와일드카드 작업을 허용하지 않아야 합니다.

설명: 이 컨트롤은 사용자가 만든 IAM ID 기반 정책에 * 와일드카드를 사용하여 모든 서비스에 대한 모든 작업에 대한 권한을 부여하는 Allow 문이 있는지 여부를 확인합니다. 정책 문에 'Effect': 'Allow'와 'Action': 'Service:*'가 포함되어 있으면 컨트롤이 실패합니다. 예를 들어 정책의 다음 명령문은 검사에 불합격합니다.

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

'Effect': 'Allow'와 'NotAction': 'service:'를 사용하는 경우에도 컨트롤이 실패합니다. 이 경우 NotAction 요소는 NotAction에 지정된 작업을 제외하고 AWS 서비스의 모든 작업에 대한 액세스를 제공합니다. 이 컨트롤은 고객 관리형 IAM 정책에만 적용됩니다. AWS에서 관리하는 IAM 정책에는 적용되지 않습니다. AWS 서비스에 권한을 할당하는 경우 IAM 정책에서 허용되는 IAM 작업의 범위를 지정하는 것이 중요합니다. IAM 작업을 필요한 작업으로만 제한해야 합니다. 이렇게 하면 최소 권한 권한을 프로비전할 수 있습니다. 정책이 권한이 필요하지 않을 수 있는 IAM 보안 주체에 연결된 경우 지나치게 허용되는 정책으로 인해 권한 상승이 발생할 수 있습니다. 경우에 따라 DescribeFlowLogs 및 DescribeAvailabilityZones와 같은 유사한 접두사를 가진 IAM 작업을 허용할 수 있습니다. 이러한 권한이 부여된 경우 접미사 와일드카드를 공통 접두사에 추가할 수 있습니다. 예를 들어 ec2:Describe입니다.

접두사가 있는 IAM 작업을 접미사가 있는 와일드카드에 사용하는 경우 이 컨트롤은 합격입니다. 예를 들어 정책의 다음 명령문은 검사에 합격합니다.

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

또한 이러한 방식으로 관련 IAM 작업을 그룹화하면 IAM 정책 크기 제한을 초과하지 않도록 방지할 수 있습니다.

심각도: 낮음

IAM 정책은 그룹 또는 역할에만 연결되어야 합니다.

설명: 기본적으로 IAM 사용자, 그룹 및 역할은 AWS 리소스에 액세스할 수 없습니다. IAM 정책은 사용자, 그룹 또는 역할에 권한을 부여하는 방법입니다. IAM 정책은 사용자가 아닌 그룹 및 역할에 직접 적용하는 것이 좋습니다. 그룹 또는 역할 수준에서 권한을 할당하면 사용자 수가 증가할 때 액세스 관리 복잡성이 감소합니다. 액세스 관리 복잡성을 줄이면 보안 주체가 실수로 과도한 권한을 받거나 유지할 수 있는 기회가 줄어들 수 있습니다.

심각도: 낮음

전체 ":" 관리 권한을 허용하는 IAM 정책을 만들면 안 됩니다.

설명: IAM 정책은 사용자, 그룹 또는 역할에 권한이 부여되는 수단입니다. 작업을 수행하는 데 필요한 권한만 부여하는 최소 권한을 부여하는 것이 좋습니다. 사용자가 수행해야 할 작업을 결정한 다음, 전체 관리 권한을 허용하는 대신 사용자가 해당 작업만 수행할 수 있는 정책을 만듭니다. 너무 많은 권한으로 시작했다가 나중에 권한을 줄이는 것보다는 최소 권한으로 시작하고 필요에 따라 추가 권한을 부여하는 것이 더 안전합니다. 사용자가 작업을 수행하는 데 필요한 최소 권한 대신 전체 관리 권한을 제공하면 리소스가 원치 않는 작업에 노출될 수 있습니다. "Effect": "Allow"와 "Resource": "" 위에 "Action": "" 문이 있는 IAM 정책을 제거해야 합니다.

심각도: 높음

IAM 보안 주체는 모든 KMS 키에 서 암호 해독 작업을 허용하는 IAM 인라인 정책을 사용하지 않아야 합니다.

설명: IAM ID(역할, 사용자 또는 그룹)에 포함된 인라인 정책이 모든 KMS 키에 대한 AWS KMS 암호 해독 작업을 허용하는지 여부를 확인합니다. 이 컨트롤은 자동화된 추론 엔진인 Zelkova를 사용하여 AWS 계정에서 비밀에 대한 광범위한 액세스 권한을 부여할 수 있는 정책의 유효성을 검사하고 경고합니다. 인라인 정책의 모든 KMS 키에 대해 작업이 허용되는 경우 kms:Decrypt 이 컨트롤이 실패합니다 kms:ReEncryptFrom . AWS KMS를 사용하면 KMS 키를 사용하여 암호화된 데이터에 대한 액세스 권한을 얻을 수 있는 사용자를 제어할 수 있습니다. IAM 정책은 ID(사용자, 그룹 또는 역할)가 어떤 리소스에서 어떤 작업을 수행할 수 있는지 정의합니다. AWS 보안 모범 사례에 따라 최소 권한을 허용하는 것이 좋습니다. 즉, 작업을 수행하는 데 필요한 키에 대한 권한만 ID에 부여해야 합니다. 그렇지 않으면 사용자가 데이터에 적합하지 않은 키를 사용할 수 있습니다. 모든 키에 대한 권한을 부여하지 말고, 사용자가 암호화된 데이터에 액세스하는 데 필요한 최소 키 세트를 결정합니다. 그런 다음, 사용자가 해당 키만 사용할 수 있도록 정책을 디자인합니다. 예를 들어 모든 KMS 키에 대한 사용 권한을 허용하지 kms:Decrypt 않습니다. 계정에 해당하는 특정 지역의 키에 대한 권한만 허용합니다. 최소 권한 원칙을 채택하면 의도하지 않은 데이터 공개 위험을 줄일 수 있습니다.

심각도: 보통

람다 함수는 퍼블릭 액세스를 제한해야 합니다.

설명: 람다 함수 리소스 기반 정책은 공용 액세스를 제한해야 합니다. 이 권장 사항은 내부 보안 주체의 액세스를 확인하지 않습니다. 최소 권한 리소스 기반 정책을 사용하여 권한 있는 보안 주체만 함수에 액세스할 수 있도록 제한해야 합니다.

심각도: 높음

모든 IAM 사용자에게 MFA를 사용하도록 설정해야 합니다.

설명: 모든 IAM 사용자는 MFA(다단계 인증)를 사용하도록 설정해야 합니다.

심각도: 보통

"루트" 계정에 MFA를 사용하도록 설정해야 합니다..

설명: 루트 계정은 계정에서 가장 권한이 있는 사용자입니다. MFA는 사용자 이름 및 암호 위에 보호 계층을 추가합니다. MFA를 사용하면 사용자가 AWS 웹 사이트에 로그인할 때 사용자 이름 및 암호와 AWS MFA 디바이스의 인증 코드를 입력해야 합니다. 루트 계정에 가상 MFA를 사용하는 경우 사용된 디바이스가 개인 디바이스가 아닌 것이 좋습니다. 그 대신 개인용 디바이스와 독립적으로 요금이 청구되고 보안이 유지되는 전용 모바일 디바이스(태블릿 또는 휴대폰)를 사용하세요. 이렇게 하면 디바이스 분실, 디바이스 거래 또는 디바이스를 소유한 개인의 퇴사로 인해 MFA에 대한 액세스가 손실될 위험이 줄어듭니다.

심각도: 낮음

IAM 사용자의 암호 정책에 강력한 구성이 있어야 합니다.

설명: IAM 사용자의 계정 암호 정책이 다음 최소 구성을 사용하는지 여부를 확인합니다.

RequireUppercaseCharacters - 암호에 하나 이상의 대문자가 필요합니다. (기본값 = true)
RequireLowercaseCharacters - 암호에 하나 이상의 소문자가 필요합니다. (기본값 = true)
RequireNumbers - 암호에 하나 이상의 번호가 필요합니다. (기본값 = true)
MinimumPasswordLength- 암호 최소 길이입니다. (기본값 = 7 이상)
PasswordReusePrevention - 재사용을 허용하기 전의 암호 수입니다. (기본값 = 4)
MaxPasswordAge - 암호가 만료되기 전의 일 수입니다. (기본값 = 90)

심각도: 보통

AWS 계정에서 비활성 ID의 사용 권한을 취소해야 합니다.

설명: 클라우드용 Microsoft Defender 지난 45일 동안 AWS 계정 내의 리소스에 대해 아무 작업도 수행하지 않은 ID를 발견했습니다. 클라우드 환경의 공격 노출 영역을 줄이기 위해 비활성 ID의 사용 권한을 취소하는 것이 좋습니다.

심각도: 보통

루트 계정 액세스 키가 없어야 합니다.

설명: 루트 계정은 AWS 계정에서 가장 권한이 있는 사용자입니다. AWS 액세스 키는 지정된 AWS 계정에 대한 프로그래밍 방식 액세스 권한을 제공합니다. 루트 계정과 연결된 모든 액세스 키를 제거하는 것이 좋습니다. 루트 계정과 연결된 액세스 키를 제거하면 계정이 손상될 수 있는 벡터가 제한됩니다. 또한 루트 액세스 키를 제거하는 경우 최소 권한만 있는 역할 기반 계정을 만들어서 사용하는 것이 좋습니다.

심각도: 높음

S3 블록 퍼블릭 액세스 설정을 사용하도록 설정해야 합니다.

설명: S3 버킷에 대해 공용 액세스 차단 설정을 사용하도록 설정하면 중요한 데이터 누출을 방지하고 악의적인 작업으로부터 버킷을 보호할 수 있습니다.

심각도: 보통

버킷 수준에서 S3 블록 퍼블릭 액세스 설정을 사용하도록 설정해야 합니다.

설명: 이 컨트롤은 S3 버킷에 버킷 수준 공용 액세스 블록이 적용되었는지 여부를 확인합니다. 다음 설정 중에서 false로 설정된 경우 이 컨트롤이 실패합니다.

ignorePublicAcls
blockPublicPolicy
blockPublicAcls
restrictPublicBuckets는 S3 버킷 수준에서 공용 액세스를 차단하여 개체에 공용 액세스 권한이 없도록 하는 컨트롤을 제공합니다. ACL(액세스 제어 목록), 버킷 정책 또는 둘 모두를 통해 버킷 및 개체에 퍼블릭 액세스 권한이 부여됩니다. S3 버킷에 대한 퍼블릭 액세스를 허용할 생각이 없다면 버킷 수준 Amazon S3 퍼블릭 액세스 차단 기능을 구성해야 합니다.

심각도: 높음

S3 버킷 퍼블릭 읽기 액세스를 제거해야 합니다.

설명: S3 버킷에 대한 공용 읽기 액세스를 제거하면 데이터를 보호하고 데이터 위반을 방지할 수 있습니다.

심각도: 높음

S3 버킷 퍼블릭 쓰기 액세스를 제거해야 합니다.

설명: S3 버킷에 대한 공용 쓰기 액세스를 허용하면 비용을 절감하거나, 몸값을 위해 파일을 암호화하거나, 버킷을 사용하여 맬웨어를 운영하는 등의 악의적인 작업에 취약해질 수 있습니다.

심각도: 높음

Secrets Manager 비밀에서는 자동 회전을 사용하도록 설정해야 합니다.

설명: 이 컨트롤은 AWS 비밀 관리자에 저장된 비밀이 자동 회전으로 구성되었는지 여부를 확인합니다. Secrets Manager는 조직의 보안 태세를 강화하는 데 도움이 됩니다. 비밀에는 데이터베이스 자격 증명, 암호, 타사 API 키가 포함됩니다. Secrets Manager를 사용하여 비밀을 중앙에 저장하고, 비밀을 자동으로 암호화하고, 비밀 액세스 권한을 제어하고, 비밀을 안전하게 자동으로 회전할 수 있습니다. Secrets Manager는 비밀을 회전할 수 있습니다. 회전을 사용하여 장기 비밀을 단기 비밀로 바꿀 수 있습니다. 비밀을 회전하면 권한 없는 사용자가 손상된 비밀을 사용할 수 있는 기간이 제한됩니다. 이러한 이유로 비밀을 자주 회전해야 합니다. 회전에 대한 자세한 내용은 AWS Secrets Manager 사용자 가이드의 Rotating your AWS Secrets Manager secrets(영문)를 참조하세요.

심각도: 보통

중지된 EC2 인스턴스는 지정된 시간 후에 제거해야 합니다.

설명: 이 컨트롤은 EC2 인스턴스가 허용된 일 수를 초과하여 중지되었는지 여부를 확인합니다. EC2 인스턴스는 허용되는 최대 기간(기본적으로 30일)보다 오랫동안 중지된 경우 이 검사에 실패합니다. 검사에 불합격했다는 것은 EC2 인스턴스가 상당히 오랫동안 실행되지 않았다는 뜻입니다. EC2 인스턴스가 적극적으로 유지 관리되지 않으므로(분석, 패치, 업데이트) 보안 위험이 발생합니다. 나중에 시작되면 적절한 유지 관리가 부족하여 AWS 환경에서 예기치 않은 문제가 발생할 수 있습니다. 실행되지 않는 상태로 시간이 지나도 EC2 인스턴스를 안전하게 유지 관리하려면 주기적으로 인스턴스를 시작하여 유지 관리를 수행한 후 중지합니다. 자동화된 프로세스를 사용하는 것이 가장 좋습니다.

심각도: 보통

AWS 환경에서 사용되지 않는 ID를 제거해야 합니다(미리 보기)

설명: 비활성 ID는 지난 90일 동안 리소스에 대해 아무 작업도 수행하지 않은 인간 및 비인간 엔터티입니다. AWS 계정에서 위험 수준이 높은 권한이 있는 비활성 IAM ID는 그대로 남아 있는 경우 공격하기 쉬울 수 있으며 조직은 자격 증명 오용 또는 악용에 노출될 수 있습니다. 사용하지 않는 ID를 사전에 검색하고 대응하면 권한이 없는 엔터티가 AWS 리소스에 액세스하지 못하도록 방지할 수 있습니다.

심각도: 보통

GCP ID 및 액세스 권장 사항

암호화 키에는 세 명 이상의 사용자가 있어야 함

설명: 이 권장 사항은 키 링, 프로젝트 및 조직에 대한 IAM 정책을 평가합니다. 역할/소유자, 역할/cloudkms.cryptoKeyEncrypterDecrypter, roles/cloudkms.cryptoKeyEncrypter, roles/cloudkms.cryptoKeyDecrypter, roles/cloudkms.cryptoKeyDecrypter, roles/cloudkms.signer, roles/cloudkms.signerVerifier 등 클라우드 KMS 키를 사용하여 데이터를 암호화, 암호 해독 또는 서명할 수 있는 역할이 있는 보안 주체를 검색합니다.

심각도: 보통

프로젝트에 대해 API 키를 만들지 않아야 함

설명: 키는 브라우저 내에서와 같이 공개적으로 볼 수 있거나 키가 있는 디바이스에서 액세스할 수 있기 때문에 안전하지 않습니다. 대신 표준 인증 흐름을 사용하는 것이 좋습니다.

API 키 사용과 관련된 보안 위험은 다음과 같습니다.

API 키는 간단한 암호화된 문자열입니다.
API 키는 API 요청을 만드는 사용자 또는 애플리케이션을 식별하지 않습니다.
API 키는 일반적으로 클라이언트에서 액세스할 수 있으므로 API 키를 쉽게 검색하고 도용할 수 있습니다.

API 키를 사용하는 보안 위험을 방지하려면 대신 표준 인증 흐름을 사용하는 것이 좋습니다.

심각도: 높음

API 키가 애플리케이션에 액세스해야 하는 API로만 제한되어야 함

설명: API 키는 브라우저 내에서와 같이 공개적으로 볼 수 있거나 키가 있는 디바이스에서 액세스할 수 있기 때문에 안전하지 않습니다. 애플리케이션에 필요한 API만 사용(호출)하도록 API 키를 제한하는 것이 좋습니다.

API 키 사용과 관련된 보안 위험은 다음과 같습니다.

API 키는 간단한 암호화된 문자열입니다.
API 키는 API 요청을 만드는 사용자 또는 애플리케이션을 식별하지 않습니다.
API 키는 일반적으로 클라이언트에서 액세스할 수 있으므로 API 키를 쉽게 검색하고 도용할 수 있습니다.

이러한 잠재적 위험에 비추어 Google은 API 키 대신 표준 인증 흐름을 사용하는 것이 좋습니다. 그러나 특정한 경우에서는 API 키가 더 적합합니다. 예를 들어 Google Cloud Translation API를 사용해야 하지만 백 엔드 서버가 필요하지 않은 모바일 애플리케이션이 있는 경우 API 키는 해당 API에 인증하는 가장 간단한 방법입니다.

최소 권한을 제공하여 공격 표면을 줄이기 위해 API 키는 애플리케이션에 필요한 API만 사용(호출)하도록 제한할 수 있습니다.

심각도: 높음

API 키를 지정한 호스트와 앱에서만 사용되도록 제한되어야 함

설명: 무제한 키는 브라우저 내에서와 같이 공개적으로 볼 수 있거나 키가 있는 디바이스에서 액세스할 수 있기 때문에 안전하지 않습니다. API 키 사용을 신뢰할 수 있는 호스트, HTTP 참조자 및 앱으로 제한하는 것이 좋습니다.

API 키 사용과 관련된 보안 위험은 다음과 같습니다.

API 키는 간단한 암호화된 문자열입니다.
API 키는 API 요청을 만드는 사용자 또는 애플리케이션을 식별하지 않습니다.
API 키는 일반적으로 클라이언트에서 액세스할 수 있으므로 API 키를 쉽게 검색하고 도용할 수 있습니다.

이러한 잠재적 위험을 고려하여 Google은 API 키 대신 표준 인증 흐름을 사용하는 것이 좋습니다. 그러나 특정한 경우에서는 API 키가 더 적합합니다. 예를 들어 Google Cloud Translation API를 사용해야 하지만 백 엔드 서버가 필요하지 않은 모바일 애플리케이션이 있는 경우 API 키는 해당 API에 인증하는 가장 간단한 방법입니다.

공격 벡터를 줄이기 위해 API 키는 신뢰할 수 있는 호스트, HTTP 참조자 및 애플리케이션으로만 제한될 수 있습니다.

심각도: 높음

90일마다 API 키가 순환되어야 함

설명: 90일마다 API 키를 회전하는 것이 좋습니다.

API 키 사용과 관련된 보안 위험은 다음과 같습니다.

API 키는 간단한 암호화된 문자열입니다.
API 키는 API 요청을 만드는 사용자 또는 애플리케이션을 식별하지 않습니다.
API 키는 일반적으로 클라이언트에서 액세스할 수 있으므로 API 키를 쉽게 검색하고 도용할 수 있습니다.

이러한 잠재적 위험 때문에 Google은 API 키 대신 표준 인증 흐름을 사용하는 것이 좋습니다. 그러나 특정한 경우에서는 API 키가 더 적합합니다. 예를 들어 Google Cloud Translation API를 사용해야 하지만 백 엔드 서버가 필요하지 않은 모바일 애플리케이션이 있는 경우 API 키는 해당 API에 인증하는 가장 간단한 방법입니다.

키를 도난당한 후에는 만료가 없으므로 프로젝트 소유자가 키를 해지하거나 다시 생성하지 않는 한 무기한으로 사용될 수 있습니다. API 키를 회전하면 손상되거나 종료된 계정과 연결된 액세스 키를 사용할 수 있는 기간이 감소합니다.

손실, 금이 가거나 도난되었을 수 있는 이전 키를 사용하여 데이터에 액세스할 수 없도록 API 키를 회전해야 합니다.

심각도: 높음

90일 기간 내에 KMS 암호화 키가 순환되어야 함

설명: Google Cloud 키 관리 서비스 유용하고 우아한 액세스 제어 관리를 위해 설계된 계층 구조에 암호화 키를 저장합니다. 회전 일정의 형식은 사용되는 클라이언트 라이브러리에 따라 다릅니다. gcloud 명령줄 도구의 경우 다음 회전 시간은 "ISO" 또는 "RFC3339" 형식이어야 하며 회전 기간은 "INTEGER[UNIT]" 형식이어야 합니다. 여기서 단위는 초(초), 분(m), 시간(h) 또는 일(d) 중 하나일 수 있습니다. 키 회전 기간 및 시작 시간을 설정합니다. 새 키 버전이 자동으로 생성되는 시점 사이의 시간인 지정된 "회전 기간"을 사용하여 키를 만들 수 있습니다. 지정된 다음 회전 시간으로 키를 만들 수도 있습니다. 키는 특정 목적에 사용되는 "암호화 키"를 나타내는 명명된 개체입니다. "암호화"에 사용되는 실제 비트인 키 자료는 새 키 버전이 만들어질 때 시간이 지남에 따라 변경 될 수 있습니다. 키는 일부 "데이터 모음"을 보호하는 데 사용됩니다. 파일 컬렉션을 동일한 키로 암호화할 수 있으며 해당 키에 대한 "암호 해독" 권한이 있는 사용자는 해당 파일의 암호를 해독할 수 있습니다. 따라서 "회전 기간"이 특정 시간으로 설정되어 있는지 확인해야 합니다.

심각도: 보통

프로젝트 소유권 할당/변경에 대한 로그 메트릭 필터 및 경고가 있어야 함

설명: 사용자/서비스 계정에 대한 불필요한 프로젝트 소유권 할당 및 프로젝트 및 리소스의 추가 오용을 방지하기 위해 모든 "역할/소유자" 할당을 모니터링해야 합니다. 기본 역할 "역할/소유자"에 역할이 할당된 멤버(사용자/서비스 계정)은 프로젝트 소유자입니다. 프로젝트 소유자는 역할이 속한 프로젝트에 대한 모든 권한을 가집니다. 이러한 내용은 아래에 간략하게 정리되어 있습니다.

프로젝트 내의 모든 GCP 서비스에 대한 모든 뷰어 권한
프로젝트 내의 모든 GCP 서비스의 상태를 수정하는 작업에 대한 권한
프로젝트 및 프로젝트 내의 모든 리소스에 대한 역할 및 권한 관리
소유자 역할을 구성원(사용자/서비스 계정)에게 부여하는 프로젝트에 대한 청구를 설정하면 해당 멤버가 IAM(ID 및 액세스 관리) 정책을 수정할 수 있습니다. 따라서 멤버가 IAM 정책을 관리할 정당한 목적이 있는 경우에만 소유자 역할을 부여합니다. 이는 프로젝트 IAM 정책에 중요한 액세스 제어 데이터가 포함되어 있기 때문입니다. 최소한의 사용자 집합으로 IAM 정책을 관리할 수 있으면 필요할 수 있는 모든 감사가 간소화됩니다. 프로젝트 소유권은 프로젝트에 대한 최고 수준의 권한을 가집니다. 프로젝트 리소스의 오용을 방지하려면 위에서 언급한 프로젝트 소유권 할당/변경 작업을 모니터링하고 관련 수신자에게 경고해야 합니다.
프로젝트 소유권 초대 보내기
사용자에 의한 프로젝트 소유권 초대 수락/거부
사용자/서비스 계정에 추가 role\Owner
사용자/서비스 계정 제거 role\Owner

심각도: 낮음

프로젝트에 대해 oslogin을 사용하도록 설정해야 함

설명: OS 로그인을 사용하도록 설정하면 SSH 인증서가 IAM 사용자에게 바인딩되고 효과적인 SSH 인증서 관리가 용이합니다. osLogin을 사용하도록 설정하면 인스턴스에 연결하는 데 사용되는 SSH 키가 IAM 사용자와 매핑됩니다. IAM 사용자에 대한 액세스 권한을 해지하면 해당 특정 사용자와 연결된 모든 SSH 키가 해지됩니다. 중앙 집중식 및 자동화된 SSH 키 쌍 관리를 용이하게 하며, 손상된 SSH 키 쌍에 대한 응답 및/또는 외부/타사/공급업체 사용자의 해지와 같은 사례를 처리하는 데 유용합니다. 프로젝트가 비정상 상태가 되는 인스턴스를 확인하려면 "모든 인스턴스에 대해 오슬로긴을 사용하도록 설정했는지 확인"이라는 권장 사항을 참조하세요.

심각도: 보통

모든 인스턴스에 대해 oslogin이 사용하도록 설정되어 있는지 확인

심각도: 보통

모든 서비스 및 프로젝트의 모든 사용자에 대해 올바르게 클라우드 감사 로깅이 구성되어야 함

설명: 클라우드 감사 로깅은 모든 관리자 활동을 추적하고 사용자 데이터에 대한 읽기, 쓰기 액세스를 추적하도록 구성하는 것이 좋습니다.

Cloud 감사 로깅은 각 프로젝트, 폴더, 조직에 대해 두 개의 감사 로그(관리자 작업 및 데이터 액세스)를 유지합니다.

관리자 활동 로그에는 API 호출에 대한 로그 항목 또는 리소스의 구성 또는 메타데이터를 수정하는 기타 관리 작업이 포함됩니다.
관리자 활동 감사 로그는 모든 서비스에 대해 사용하도록 설정되며 구성할 수 없습니다.
데이터 액세스 감사 로그는 사용자가 제공한 데이터를 만들기, 수정 또는 읽는 API 호출을 로그합니다. 이들은 기본적으로 사용하지 않도록 설정되어 있으며 이를 사용하도록 설정해야 합니다.

데이터 액세스 감사 로그 정보에는 세 가지 종류가 있습니다.

관리자 읽기: 메타데이터 또는 구성 정보를 읽는 작업을 기록합니다. 관리자 활동 감사 로그는 비활성화할 수 없는 메타데이터 및 구성 정보의 쓰기를 기록합니다.
데이터 읽기: 사용자가 제공한 데이터를 읽는 작업을 기록합니다.
데이터 쓰기: 사용자가 제공한 데이터를 쓰는 작업을 기록합니다.

다음과 같은 방식으로 효과적인 기본 감사 구성을 구성하는 것이 좋습니다.

로그 유형은 DATA_READ(사용자 활동 추적을 기록하기 위해) 및 DATA_WRITES(사용자 데이터에 대한 변경 내용/변조를 기록하기 위해)로 설정됩니다.
감사 구성은 데이터 액세스 감사 로그 기능에서 지원하는 모든 서비스에 대해 사용하도록 설정됩니다.
모든 사용자에 대해 로그를 캡처해야 합니다. 즉, 감사 구성 섹션에는 제외된 사용자가 없습니다. 이렇게 하면 감사 구성 재정의가 요구 사항과 모순되지 않습니다.

심각도: 보통

Cloud KMS 암호화 키가 익명으로 또는 공개적으로 액세스할 수 없는지 확인

설명: 클라우드 KMS 암호화 키의 IAM 정책은 익명 및/또는 공용 액세스를 제한하는 것이 좋습니다. "allUsers" 또는 "allAuthenticatedUsers"에 권한을 부여하면 누구나 데이터 세트에 액세스할 수 있습니다. 중요한 데이터가 해당 위치에 저장된 경우 이러한 액세스는 바람직하지 않을 수 있습니다. 이 경우 클라우드 KMS 암호화 키에 대한 익명 및/또는 공용 액세스가 허용되지 않는지 확인합니다.

심각도: 높음

설명: Gmail 계정과 같은 개인 계정 대신 회사 로그인 자격 증명을 사용합니다. 클라우드 플랫폼 리소스에 대한 가시성 향상, 감사 및 액세스 제어에 완전 관리형 회사 Google 계정을 사용하는 것이 좋습니다. 개인 계정 등의 사용자 조직 외부에 기반을 둔 Gmail 계정은 비즈니스 목적으로 사용하면 안 됩니다.

심각도: 높음

프로젝트 수준에서 IAM 사용자에게 서비스 계정 사용자 또는 서비스 계정 토큰 Creator 역할을 할당하지 않아야 함

설명: 프로젝트 수준에서 사용자에게 역할을 할당하는 대신 특정 서비스 계정의 사용자에게 "서비스 계정 사용자(iam.serviceAccountUser)" 및 "서비스 계정 토큰 작성자(iam.serviceAccountTokenCreator)" 역할을 할당하는 것이 좋습니다. 서비스 계정은 개별 최종 사용자가 아닌 애플리케이션 또는 VM(가상 머신)에 속하는 특별한 Google 계정입니다. Application/VM-Instance는 사용자가 직접 관여하지 않도록 서비스 계정을 사용하여 서비스의 Google API를 호출합니다. 서비스 계정은 ID일 뿐만 아니라 IAM 정책이 연결된 리소스입니다. 이러한 정책은 서비스 계정을 사용할 수 있는 사용자를 결정합니다. 앱 엔진 및 컴퓨팅 엔진 인스턴스(예: App Engine Deployer 또는 Compute Instance Admin)를 업데이트하는 IAM 역할이 있는 사용자는 이러한 인스턴스를 실행하는 데 사용되는 서비스 계정으로 코드를 효과적으로 실행할 수 있으며 서비스 계정이 액세스할 수 있는 모든 간접적 서비스 리소스에 대한 액세스 권한을 가져올 수 있습니다. 마찬가지로 컴퓨팅 엔진 인스턴스에 대한 SSH 액세스는 해당 인스턴스/서비스 계정으로 코드를 실행하는 기능을 제공할 수도 있습니다. 비즈니스 요구 사항에 따라 프로젝트에 대해 구성된 여러 사용자 관리 서비스 계정이 있을 수 있습니다. 프로젝트의 사용자에게 "iam.serviceAccountUser" 또는 "iam.serviceAserviceAccountTokenCreatorccountUser" 역할을 부여하면 사용자는 나중에 만들 수 있는 서비스 계정을 포함하여 프로젝트의 모든 서비스 계정에 액세스할 수 있습니다. 이로 인해 서비스 계정 및 해당 "컴퓨팅 엔진 인스턴스"를 사용하여 권한 상승이 발생할 수 있습니다. "최소 권한" 모범 사례를 구현하기 위해 IAM 사용자에게 프로젝트 수준에서 "서비스 계정 사용자" 또는 "서비스 계정 토큰 작성자" 역할을 할당해서는 안 됩니다. 대신 이러한 역할은 특정 서비스 계정의 사용자에게 할당되어 해당 사용자에게 서비스 계정에 대한 액세스 권한을 부여해야 합니다. "서비스 계정 사용자"는 사용자가 서비스 계정을 장기 실행 작업 서비스에 바인딩할 수 있도록 허용하는 반면, "서비스 계정 토큰 작성자" 역할은 사용자가 서비스 계정의 ID를 직접 가장(또는 어설션)할 수 있도록 합니다.

심각도: 보통

설명: 사용자에게 KMS 관련 역할을 할당하는 동안 '의무 분리' 원칙을 적용하는 것이 좋습니다. 기본 제공/미리 정의된 IAM 역할 "Cloud KMS 관리자"를 통해 사용자/ID는 서비스 계정을 만들기, 삭제 및 관리할 수 있습니다. 기본 제공/미리 정의된 IAM 역할을 Cloud KMS CryptoKey Encrypter/Decrypter 사용하면 사용자/ID(관련 리소스에 대한 적절한 권한 포함)가 암호화 키를 사용하여 미사용 데이터를 암호화하고 암호 해독할 수 있습니다. 기본 제공/미리 정의된 IAM 역할을 Cloud KMS CryptoKey Encrypter 사용하면 사용자/ID(관련 리소스에 대한 적절한 권한 포함)가 암호화 키를 사용하여 미사용 데이터를 암호화할 수 있습니다. 기본 제공/미리 정의된 IAM 역할을 Cloud KMS Crypto Key Decrypter 사용하면 사용자/ID(관련 리소스에 대한 적절한 권한 포함)가 암호화 키를 사용하여 미사용 데이터의 암호를 해독할 수 있습니다. 업무 분리는 한 개인이 악의적인 작업을 완료하는 데 필요한 모든 권한을 갖지 않도록 하는 개념입니다. Cloud KMS에서 이 작업은 키를 사용하여 사용자가 일반적으로 액세스할 수 없는 데이터에 액세스하고 암호를 해독하는 작업일 수 있습니다. 업무 분리는 대규모 조직에서 일반적으로 사용되는 비즈니스 제어로, 보안 또는 개인 정보 보호 인시던트 및 오류를 방지하는 데 도움이 됩니다. 모범 사례로 간주됩니다. 클라우드 KMS 관리자 및 Cloud KMS CryptoKey Encrypter/Decrypter모든 , Cloud KMS CryptoKey EncrypterCloud KMS CryptoKey Decrypter 역할이 동시에 할당된 사용자는 없어야 합니다.

심각도: 높음

설명: 사용자에게 서비스 계정 관련 역할을 할당하는 동안 '의무 분리' 원칙을 적용하는 것이 좋습니다. 기본 제공/미리 정의된 IAM 역할 "서비스 계정 관리자"를 통해 사용자/ID는 서비스 계정을 만들고 삭제 및 관리할 수 있습니다. 기본 제공/미리 정의된 IAM 역할 "서비스 계정 사용자"를 사용하면 사용자/ID(컴퓨팅 및 앱 엔진에 대한 적절한 권한이 있음)가 서비스 계정을 앱/컴퓨팅 인스턴스에 할당할 수 있습니다. 업무 분리는 한 개인이 악의적인 작업을 완료하는 데 필요한 모든 권한을 갖지 않도록 하는 개념입니다. 클라우드 IAM - 서비스 계정에서 이는 서비스 계정을 사용하여 사용자가 일반적으로 액세스할 수 없는 리소스에 액세스하는 것과 같은 작업일 수 있습니다. 업무 분리는 대규모 조직에서 일반적으로 사용되는 비즈니스 제어로, 보안 또는 개인 정보 보호 인시던트 및 오류를 방지하는 데 도움이 됩니다. 모범 사례로 간주됩니다. 어떤 사용자도 "서비스 계정 관리자"와 "서비스 계정 사용자" 역할을 동시에 할당받아서는 안 됩니다.

심각도: 보통

서비스 계정에 관리자 권한이 없어야 함

설명: 서비스 계정은 개별 최종 사용자가 아닌 애플리케이션 또는 VM에 속하는 특수 Google 계정입니다. 애플리케이션은 사용자가 직접 관여하지 않도록 서비스 계정을 사용하여 서비스의 Google API를 호출합니다. ServiceAccount에 대한 관리자 액세스를 사용하지 않는 것이 좋습니다. 서비스 계정은 할당된 역할에 따라 결정될 수 있는 리소스(애플리케이션 또는 VM)의 서비스 수준 보안을 나타냅니다. 관리자 권한으로 ServiceAccount를 등록하면 할당된 애플리케이션 또는 VM에 대한 모든 권한이 부여됩니다. ServiceAccount 액세스 보유자는 사용자 개입 없이 삭제, 변경 설정 업데이트 등과 같은 중요한 작업을 수행할 수 있습니다. 이러한 이유로 서비스 계정에 관리자 권한이 없는 것이 좋습니다.

심각도: 보통

모든 로그 항목에 대해 싱크가 구성되어야 함

설명: 모든 로그 항목의 복사본을 내보내는 싱크를 만드는 것이 좋습니다. 이를 통해 여러 프로젝트의 로그를 집계하고 SIEM(보안 정보 및 이벤트 관리)으로 내보낼 수 있습니다. 로그 항목은 Stackdriver 로깅에 보관됩니다. 로그를 집계하려면 SIEM으로 내보내세요. 더 오래 유지하려면 로그 싱크를 설정하는 것이 좋습니다. 내보내기에는 내보낼 로그 항목을 선택하는 필터 작성과 클라우드 스토리지, BigQuery 또는 Cloud Pub/Sub에서 대상 선택이 포함됩니다. 필터와 대상은 싱크라는 개체에 보관됩니다. 모든 로그 항목을 싱크로 내보내려면 싱크에 대해 구성된 필터가 없는지 확인합니다. 프로젝트, 조직, 폴더, 청구 계정에서 싱크를 만들 수 있습니다.

심각도: 낮음

감사 구성 변경에 대한 로그 메트릭 필터 및 경고가 있어야 함

설명: GCP(Google Cloud Platform) 서비스는 감사 로그 항목을 관리자 활동 및 데이터 액세스 로그에 씁니다. 항목은 GCP 프로젝트 내에서 "누가 무엇을 했는지, 어디서, 언제?" 질문에 대답하는 데 도움이 됩니다. 클라우드 감사 로깅 기록 정보에는 API 호출자의 ID, API 호출 시간, API 호출자의 원본 IP 주소, 요청 매개 변수, GCP 서비스에서 반환한 응답 요소가 포함됩니다. Cloud 감사 로깅은 콘솔, SDK, 명령줄 도구, 기타 GCP 서비스를 통해 이루어진 API 호출을 포함하여 계정에 대한 GCP API 호출 기록을 제공합니다. 클라우드 감사 로깅에서 생성된 관리자 활동 및 데이터 액세스 로그를 통해 보안 분석, 리소스 변경 추적 및 규정 준수 감사를 수행할 수 있습니다. 감사 구성 변경에 대한 메트릭 필터 및 경고를 구성하면 감사 구성의 권장 상태가 유지되므로 프로젝트의 모든 작업을 언제든지 감사할 수 있습니다.

심각도: 낮음

사용자 지정 역할 변경에 대한 로그 메트릭 필터 및 경고가 있어야 함

설명: IAM(ID 및 액세스 관리) 역할 만들기, 삭제 및 업데이트 작업의 변경에 대한 메트릭 필터 및 경보를 설정하는 것이 좋습니다. Google Cloud IAM은 특정 Google Cloud Platform 리소스에 대한 세분화된 액세스 권한을 부여하고 다른 리소스에 대한 원치 않는 액세스를 방지하는 미리 정의된 역할을 제공합니다. 그러나 조직별 요구 사항을 충족하기 위해 Cloud IAM은 사용자 지정 역할을 만드는 기능도 제공합니다. 조직 역할 관리자 역할 또는 IAM 역할 관리자 역할이 있는 프로젝트 소유자 및 관리자는 사용자 지정 역할을 만들 수 있습니다. 역할 만들기, 삭제 및 업데이트 작업을 모니터링하면 초기 단계에서 과도한 권한 있는 역할을 식별하는 데 도움이 됩니다.

심각도: 낮음

90일 또는 더 짧은 간격마다 서비스 계정의 사용자 관리/외부 키가 순환되어야 함

설명: 서비스 계정 키는 사용자가 특정 서비스 계정에서 액세스할 수 있는 Google 클라우드 서비스에 대한 프로그래밍 방식 요청에 서명하는 데 사용되는 키 ID(Private_key_Id) 및 프라이빗 키로 구성됩니다. 모든 서비스 계정 키를 정기적으로 회전하는 것이 좋습니다. 서비스 계정 키를 회전하면 손상되거나 종료된 계정과 연결된 액세스 키를 사용할 기회가 줄어듭니다. 손실, 금이 가거나 도난되었을 수 있는 이전 키를 사용하여 데이터에 액세스할 수 없도록 서비스 계정 키를 회전해야 합니다. 각 서비스 계정은 GCP(Google Cloud Platform)에서 관리하는 키 쌍과 연결됩니다. GCP 내에서 서비스 간 인증에 사용됩니다. Google은 키를 매일 회전합니다. GCP는 GCP 외부에서 사용할 하나 이상의 사용자 관리(외부 키 쌍이라고도 함) 키 쌍을 만들 수 있는 옵션을 제공합니다(예: 애플리케이션 기본 사용자 인증 정보와 함께 사용). 새 키 쌍을 만들 때 사용자는 프라이빗 키(Google에서 유지되지 않음)를 다운로드해야 합니다.

외부 키를 사용하면 사용자는 프라이빗 키 및 키 회전과 같은 기타 관리 작업을 안전하게 유지할 책임이 있습니다. 외부 키는 IAM API, gcloud 명령줄 도구 또는 Google Cloud Platform 콘솔의 서비스 계정 페이지에서 관리할 수 있습니다.

GCP는 키 회전을 용이하게 하기 위해 서비스 계정당 최대 10개의 외부 서비스 계정 키를 용이하게 합니다.

심각도: 보통

GCP 과도하게 프로비전된 ID에는 필요한 권한만 있어야 합니다(미리 보기).

설명: 과도하게 프로비전된 활성 ID는 사용하지 않은 권한에 액세스할 수 있는 ID입니다. 과도하게 프로비전된 활성 ID, 특히 매우 정의된 작업 및 책임이 있는 비인간 계정의 경우 사용자, 키 또는 리소스가 손상될 경우 폭발 반경을 증가시킬 수 있습니다. 최소 권한 원칙은 리소스가 작동하기 위해 필요한 정확한 리소스에만 액세스할 수 있어야 한다고 명시합니다. 이 원칙은 공격자에게 광범위한 리소스에 대한 액세스 권한을 부여하는 손상된 ID의 위험을 해결하기 위해 개발되었습니다.

다음을 통해 공유

ID 및 액세스 보안 권장 사항

Azure ID 및 액세스 권장 사항

AWS ID 및 액세스 권장 사항

Amazon Elasticsearch Service 도메인은 VPC에 있어야 합니다.

버킷 정책의 다른 AWS 계정에 부여된 Amazon S3 권한은 제한해야 합니다.

"루트" 계정을 사용하지 않습니다.

AWS KMS 키를 실수로 삭제해서는 안 됩니다.

AWS WAF 클래식 글로벌 웹 ACL 로깅을 사용하도록 설정해야 합니다.

CloudFront 배포에서는 기본 루트 개체를 구성해야 합니다.

CloudFront 배포에서는 원본 액세스 ID를 사용하도록 설정해야 합니다.

CloudTrail 로그 파일 유효성 검사를 사용하도록 설정해야 합니다.

CloudTrail을 사용하도록 설정해야 합니다.

CloudTrail 추적을 CloudWatch Logs와 통합해야 합니다.

데이터베이스 로깅을 사용하도록 설정해야 합니다.

콘솔 암호가 있는 모든 IAM 사용자의 초기 사용자 설정 중에는 액세스 키를 설정하면 안 됩니다.

AWS 지원을 통해 인시던트를 관리하기 위한 지원 역할을 만들었는지 확인해야 합니다.

90일 이하의 주기로 액세스 키를 회전해야 합니다.

모든 지역에서 AWS Config를 사용해야 합니다.

모든 지역에서 CloudTrail을 사용해야 합니다.

90일 이상 사용되지 않은 자격 증명은 사용하지 않습니다.

IAM 암호 정책에서 암호가 90일 이내에 만료되도록 합니다.

IAM 암호 정책에서 암호를 재사용하지 못하게 합니다.

IAM 암호 정책에서 소문자를 하나 이상 사용하도록 요구합니다.

IAM 암호 정책에서 숫자를 하나 이상 사용하도록 요구합니다.

IAM 암호 정책에서 기호를 하나 이상 사용하도록 요구합니다.

IAM 암호 정책에서 대문자를 하나 이상 사용하도록 요구합니다.

IAM 암호 정책에서 14자 이상의 최소 길이를 요구합니다.

GuardDuty를 사용하도록 설정해야 합니다.

"루트" 계정에 하드웨어 MFA를 사용해야 합니다.

RDS 클러스터에 대해 IAM 인증을 구성해야 합니다.

RDS 인스턴스에 대해 IAM 인증을 구성해야 합니다.

IAM 고객 관리형 정책은 모든 KMS 키에서 암호 해독 작업을 허용하지 않아야 합니다.

사용자가 만든 IAM 고객 관리 정책은 서비스에 대한 와일드카드 작업을 허용하지 않아야 합니다.

IAM 정책은 그룹 또는 역할에만 연결되어야 합니다.

전체 ":" 관리 권한을 허용하는 IAM 정책을 만들면 안 됩니다.

IAM 보안 주체는 모든 KMS 키에 서 암호 해독 작업을 허용하는 IAM 인라인 정책을 사용하지 않아야 합니다.

람다 함수는 퍼블릭 액세스를 제한해야 합니다.

모든 IAM 사용자에게 MFA를 사용하도록 설정해야 합니다.

"루트" 계정에 MFA를 사용하도록 설정해야 합니다..

IAM 사용자의 암호 정책에 강력한 구성이 있어야 합니다.

루트 계정 액세스 키가 없어야 합니다.

S3 블록 퍼블릭 액세스 설정을 사용하도록 설정해야 합니다.

버킷 수준에서 S3 블록 퍼블릭 액세스 설정을 사용하도록 설정해야 합니다.

S3 버킷 퍼블릭 읽기 액세스를 제거해야 합니다.

S3 버킷 퍼블릭 쓰기 액세스를 제거해야 합니다.

Secrets Manager 비밀에서는 자동 회전을 사용하도록 설정해야 합니다.

중지된 EC2 인스턴스는 지정된 시간 후에 제거해야 합니다.

GCP ID 및 액세스 권장 사항

관련 콘텐츠

피드백

추가 리소스