기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Amazon Verified Permissions의 데이터 보호
AWS 공동 책임 모델
-
데이터 보호를 위해 자격 증명을 보호하고 AWS 계정 AWS IAM Identity Center 또는 AWS Identity and Access Management ()를 사용하여 개별 사용자를 설정하는 것이 좋습니다IAM. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다.
-
다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.
-
각 계정에 다중 인증(MFA)을 사용하세요.
-
SSL/TLS를 사용하여 AWS 리소스와 통신합니다. TLS 1.2가 필요합니다.
-
를 사용하여 API 및 사용자 활동 로깅을 설정합니다 AWS CloudTrail.
-
AWS 암호화 솔루션과 내부의 모든 기본 보안 제어를 사용합니다 AWS 서비스.
-
Amazon S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용하세요.
-
명령행 인터페이스 또는 API를 통해 AWS 에 액세스할 때 FIPS 140-2 검증된 암호화 모듈이 필요한 경우, FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 Federal Information Processing Standard(FIPS) 140-2
를 참조하세요.
-
-
고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 이름 필드와 같은 자유 양식 필드에 입력하지 않는 것이 좋습니다. 여기에는 Verified Permissions 또는 기타 콘솔, API AWS CLI또는 AWS SDKs를 AWS 서비스 사용하여 작업하는 경우가 포함됩니다. 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 자격 증명을 URL에 포함해서는 안 됩니다.
-
작업 이름에는 민감한 정보가 포함되지 않아야 합니다.
-
또한 엔터티(리소스 및 보안 주체)에는 항상 고유하고 변경 불가능하며 재사용이 불가능한 식별자를 사용하는 것이 좋습니다. 테스트 환경에서는
User유형의 엔터티 이름에jane또는bob와 같은 간단한 엔터티 식별자를 사용할 수 있습니다. 그러나 프로덕션 시스템에서는 재사용할 수 없는 고유한 값을 사용하는 것이 보안상의 이유로 중요합니다. 범용 고유 식별자(UUID) 와 같은 값을 사용하는 것이 좋습니다. 회사를 떠나는 사용자jane을 예로 들어 보겠습니다. 이 예에서는 나중에 다른 사람이 이 이름(jane)을 사용하도록 허용합니다. 해당 새 사용자는 여전히User::"jane"을 참조하는 정책에서 부여하는 모든 항목에 자동으로 액세스할 수 있게 됩니다. Verified Permissions와 Cedar는 새 사용자와 이전 사용자를 구분할 수 없습니다.이 사례는 보안 주체 및 리소스 식별자 모두에 적용됩니다. 정책에 이전 식별자가 남아 있어 의도치 않게 액세스 권한을 부여하는 일이 없도록 항상 고유성이 보장되고 재사용되지 않는 식별자를 사용하십시오.
-
Long및Decimal값을 정의하기 위해 제공하는 문자열이 각 유형의 유효 범위 내에 있는지 확인하십시오. 또한 산술 연산자를 사용해도 값이 유효 범위를 벗어나지 않도록 해야 합니다. 범위를 초과하면 작업 결과 오버플로 예외가 발생합니다. 오류가 발생하는 정책은 무시됩니다. 즉, 허용 정책이 예기치 않게 액세스를 허용하지 못하거나 금지 정책이 예기치 않게 액세스를 차단하지 못할 수 있습니다.
데이터 암호화
Amazon Verified Permissions는 정책 등의 모든 고객 데이터를 AWS 관리형 키를 사용하여 자동으로 암호화하므로 고객 관리형 키를 사용할 필요도 없고 지원되지도 않습니다.
