우수 사례

계정에서 허용되는 총 정책 수에는 한계가 있습니다. 몇 가지 전략을 사용하여 한계에 도달하지 않도록 하고 계정의 ID(사용자, 서비스 ID 또는 신뢰 프로파일)에 대한 액세스를 관리하는 데 소요되는 시간을 줄일 수 있습니다.

• 최소 권한의 원칙을 사용하고 필요한 액세스만 지정하십시오. 그러면 계정의 ID가 허용을 원하는 조치로만 제한되도록 보장하는 데 도움이 될 수 있습니다. 예를 들어, 계정 소유자가 기본적으로 계정의 모든 리소스에 대한 관리자(Administrator) 및 관리자(Manager) 액세스 권한을 부여하는 신임 정보를 공유하지 않고, 계정 및 각 서비스 인스턴스(및 연관된 키)에 대한 액세스 권한이 필요한 사용자를 위한 새 정책을 작성하십시오.
• 자원 그룹에 자원을 추가하여 필요한 정책의 수를 더 최소화하십시오. 예를 들어, 계정의 특정 리소스를 사용하는 프로젝트에 대해 작업 중인 팀이 있을 수 있습니다. 특정 리소스 그룹에 있는 리소스에만 액세스를 지정하는 정책으로 액세스 그룹 또는 신뢰 프로파일에 팀 멤버를 추가하십시오. 이 방법을 사용하면 각 팀 멤버의 각 리소스에 정책을 지정할 필요가 없습니다. 세분화된 액세스를 지정하는 데 관한 자세한 정보는 단일 키에 세분화된 액세스 권한 지정을 확인하십시오.
• 액세스 그룹을 사용하여 동일한 레벨의 액세스가 필요한 ID의 액세스 관리를 효율화합니다. 정의된 특정 정책으로 액세스 그룹을 설정한 후 해당 ID를 그룹에 추가할 수 있습니다. 그룹 구성원이 나중에 더 많은 액세스 권한이 필요한 경우, 액세스 그룹에 대한 새 정책을 정의하기만 하면 됩니다.
• 액세스 관리 태그를 사용하여 규모에 맞게 계정의 리소스에 대한 액세스를 제어합니다. 첨부된 특정 태그가 있는 리소스에만 액세스를 지정하여 정의된 정책에 대한 다중 업데이트를 피할 수 있습니다. 자세한 정보는 태그를 사용하여 리소스에 대한 액세스 제어를 참조하십시오.
• 신뢰 프로파일을 사용하여 연합 사용자에게 자동으로 권한을 부여하고 계정에 대한 리소스 액세스를 계산하십시오. 이러한 방식으로, 연합 사용자들은 그들이 적용할 수 있는 프로파일을 결정하기 위해 SAML 기반 속성을 평가함으로써 로그인 시간동안 하나 이상의 신뢰 프로파일에 매핑될 수 있습니다. 컴퓨팅 리소스에 대해 신뢰 프로파일을 사용하면 애플리케이션을 실행하기 위한 신임 정보 저장과 신임 정보의 관리 및 회전을 방지할 수 있습니다. 또한 신뢰할 수 있는 프로파일을 액세스 그룹에 추가하여 이미 작성한 정책 세트를 활용할 수 있습니다.
• 액세스 제어를 관리하고 키 리소스를 삭제할 수 있는 대상에 대해 주기적으로 감사를 실시합니다. 권한이 높은 사용자의 오류 및 오용은 계정, 서비스 인스턴스 및 서비스 인스턴스의 키로 보호되는 데이터에 손상을 줄 수 있으므로, 해당 역할의 사용자를 감사하여 적절한 액세스 권한이 유지보수되는지 확인하십시오. 작성된 새 키, 키 링 또는 서비스 인스턴스에는 기본적으로 기존 역할 정의가 적용됩니다. 인스턴스의 _관리자(Manager)_로 지정되는 새 사용자가 새 키에 액세스하거나 수정하지 않아야 하는 경우, 인스턴스 관리자가 키를 삭제하는 기능을 포함하여 기본적으로 인스턴스의 모든 키에 대한 액세스 권한이 있으므로 해당 제한사항을 특별히 지정해야 합니다.

어떻게 좋은 액세스 그룹 전략을 만들 수 있습니까?

액세스 그룹은 동일한 IAM 액세스 권한을 부여할 수 있는 그룹화의 사용자, 서비스 ID 및 신뢰할 수 있는 프로파일 조직입니다. 단일 액세스 그룹의 모든 ID는 동일한 액세스 권한을 상속합니다.

리소스 그룹 및 포함된 리소스에 대한 액세스 권한을 지정하는 논리적인 방법은 필요한 액세스 레벨마다 하나의 액세스 그룹을 작성하는 것입니다. 그런 다음 각 액세스 그룹을 이전에 작성한 리소스 그룹에 맵핑할 수 있습니다. 예를 들어 CustApp 프로젝트에 대한 액세스를 제어하려면 다음과 같은 액세스 그룹을 작성할 수 있습니다.

• 감사자-그룹
• 개발자-그룹
• 관리자-그룹

감사자-그룹의 경우 CustApp-Test와 CustApp-Prod 리소스 및 리소스 그룹에 대한 뷰어 액세스 권한을 부여하는 두 개의 액세스 정책을 지정하십시오. 개발자-그룹의 경우 CustApp-Dev 및 CustApp-Test 리소스 및 리소스 그룹에 대한 편집자 액세스 권한을 부여하는 두 개의 액세스 정책을 지정하십시오. 관리자-그룹의 경우 세 개의 모든 CustApp 리소스 그룹 및 해당 리소스에 대한 관리자 액세스 권한을 부여하는 세 개의 액세스 정책을 지정하십시오.

액세스 그룹을 작성하고 여기에 두 개의 정책을 지정하여 계정의 모든 항목에 대한 관리자 액세스 권한을 지정할 수 있습니다. 첫 번째 정책을 작성하려면 관리자(Administrator) 플랫폼 역할 및 관리자(Manager) 서비스 역할을 사용하여 계정에서 모든 ID 및 액세스 사용 서비스를 선택하십시오. 두 번째 정책을 작성하려면 관리자(Administrator) 역할이 지정된 모든 계정 관리 서비스를 선택하십시오.

플랫폼 역할

• 관리자(Administrator): 새 사용자를 초대하고 오브젝트에 역할을 지정하는 권한을 포함하여 특정 오브젝트 및 해당 "하위" 오브젝트(예: 키는 인스턴스의 하위 오브젝트임)에 대한 전체 범위의 권한이 있습니다(관리자만 역할을 지정할 수 있음). 관리자에게는 기본적으로 서비스 역할이 없습니다. 그러나 자신에게 역할을 지정할 수 있습니다.
• 편집자: 계정 레벨에서 인스턴스를 보고, 작성하고, 삭제할 수 있지만 새 사용자를 초대할 수는 없습니다. 키와 같은 서비스 인스턴스 내에서 오브젝트를 볼 수 있는 기능 외에 오브젝트에 대한 사용이 제한됩니다.
• 운영자: 계정 레벨에서 인스턴스를 볼 수 있지만 편집할 수는 없습니다. 키와 같은 서비스 인스턴스 내에서 오브젝트를 볼 수 있는 기능 외에 오브젝트에 대한 사용이 제한됩니다.
• 뷰어: 계정 레벨에서 인스턴스를 볼 수 있지만 편집할 수는 없습니다. 키와 같은 서비스 인스턴스 내에서 오브젝트를 볼 수 있는 기능 외에 오브젝트에 대한 사용이 제한됩니다.

플랫폼 역할은 전체 계정, 특정 서비스 인스턴스 또는 서비스 인스턴스 내부의 오브젝트에 지정됩니다.

다음에 적용되는 플랫폼 관리 역할을 나열합니다. Key Protect

조치	뷰어	편집자	운영자	관리자
Key Protect 인스턴스 보기
Key Protect 인스턴스 작성
Key Protect 인스턴스 삭제
새 사용자 초대 및 액세스 정책 관리

계정 레벨 역할은 기본적으로 서비스 인스턴스에 대한 특정 권한을 사용자에게 부여하지만 특정 서비스 인스턴스에 역할을 지정할 수도 있습니다. 예를 들어, 계정 편집자(인스턴스를 보기, 작성 및 삭제할 수 있지만 역할을 지정할 수 있는 기능은 없음)는 특정 서비스 인스턴스의 _관리자_를 작성하여 해당 서비스 인스턴스 내에서 역할을 지정할 수 있습니다.

서비스 역할은 서비스 인스턴스에 있는 처음 세 개의 클래스 오브젝트(전체 인스턴스, 특정 키 및 키 링)에 적용될 수 있습니다. 기본적으로 계정 역할에 인스턴스에 대한 권한이 있는 것처럼 인스턴스 관리자(Manager)는 기본적으로 키와 키 링에 대한 권한이 있습니다. 그러나 이러한 권한은 필요한 경우 더 세분화될 수 있습니다. 예를 들어, 사용자에게 특정 키 또는 키 링에 대해서만 관리자 역할을 부여하고 인스턴스 전체에 대해 더 낮은 권한 레벨을 제공할 수 있습니다.

서비스 역할은 인스턴스당 또는 계정의 모든 인스턴스에 지정될 수 있습니다.

서비스 인스턴스 역할

역할에 포함된 권한은 부가적입니다. 예를 들어, _관리자_는 _독자_에게 있는 모든 권한과 추가 권한이 있습니다. 예외는 다른 역할의 일부가 아니므로 명시적으로 설정해야 하는 kms.secrets.purge 조치를 포함하는 KeyPurge 역할입니다.

• 관리자: 특정 오브젝트에 대한 전체 권한이 있습니다(예를 들어, 키의 관리자에는 dualAuthDelete, allowedNetwork, allowedIP 등과 같은 Key Protect 정책을 읽고 업데이트하기 위한 배타적 권한뿐만 아니라 키를 랩핑하고, 랩핑 해제하고 삭제할 수 있는 기능이 있습니다.)
• 작성자: 오브젝트를 사용하는 경우(키 및 해당 메타데이터를 검색하는 기능을 포함하여) 관리자가 수행하는 권한이 대부분이지만, 일반적으로 오브젝트를 삭제하거나 사용 안함으로 설정할 수는 없습니다.
• 독자: 오브젝트를 사용할 수 있지만(예를 들어, 키 리더는 키를 랩핑하고 랩핑 해제할 수 있음), 오브젝트를 작성하거나, 삭제 또는 수정하지 않습니다.
• ReaderPlus: 표준 키 페이로드를 검색하는 추가 기능을 사용하여 리더와 동일한 권한을 갖습니다.
• KeyPurge: 4시간 후에 키를 제거하는 기능이 있습니다.
• KmipAdapterManager: KMIP 프로토콜을 통해 관리되는 리소스에 대한 액세스를 관리하는 데 필요한 모든 권한을 가집니다

다음 표에서는 서비스 액세스 역할이 Key Protect 권한에 맵핑되는 방법을 보여줍니다.

Key Protect 의 주요 리소스에 적용되는 서비스 액세스 역할을 나열합니다.

조치	독자	ReaderPlus	작성자	관리자	KeyPurge	KmipAdapterManager
키 작성
키 가져오기
키 검색
키 메타데이터 검색
키 총계 검색
키 나열
키 버전 나열
키 랩핑
키 랩핑 해제
키 다시 랩핑
키 순환
키 사용 안함
키 사용
키 삭제 스케줄
키 삭제 취소
키 삭제
키 복원
키 패치
키 동기화
4시간 후 키 제거

Key Protect 키링 리소스에 적용되는 서비스 액세스 역할을 나열합니다.

조치	독자	ReaderPlus	작성자	관리자	KeyPurge	KmipAdapterManager
키 링 작성
키 링을 나열합니다.
키 링 삭제

Key Protect 정책 리소스에 적용되는 서비스 액세스 역할을 나열합니다.

조치	독자	ReaderPlus	작성자	관리자	KeyPurge	KmipAdapterManager
키 정책 설정
키 정책 나열
인스턴스 정책 설정
인스턴스 정책 나열

토큰 리소스 가져오기에 적용되는 서비스 액세스 역할을 나열합니다.

조치	독자	ReaderPlus	작성자	관리자	KeyPurge	KmipAdapterManager
가져오기 토큰 작성
가져오기 토큰 검색

Key Protect 등록 리소스에 적용되는 서비스 액세스 역할을 나열합니다.

조치	독자	ReaderPlus	작성자	관리자	KeyPurge	KmipAdapterManager
등록 작성[^services-1]
키에 대한 등록 나열
임의의 키에 대한 등록 나열
등록 업데이트[^services-2]
등록 대체[^services-3]
등록 삭제[^services-4]

KeyPurge 역할은 키를 제거할 수 있는 기능만 부여하며 다른 서비스 액세스 역할(예: 관리자)에 대한 추가적인 역할을 고려해야 합니다.

Key Protect 의 주요 리소스에 적용되는 서비스 액세스 역할을 나열합니다.

조치	독자	ReaderPlus	작성자	관리자	KeyPurge	KmipAdapterManager
KMIP 어댑터 목록
KMIP 어댑터 만들기
KMIP 어댑터 검색
KMIP 어댑터 삭제
KMIP 어댑터의 KMIP 개체 나열하기
KMIP 어댑터에서 KMIP 개체 검색하기
KMIP 어댑터에서 KMIP 개체 삭제하기
KMIP 어댑터의 클라이언트 인증서를 나열합니다
KMIP 어댑터에 클라이언트 인증서 추가하기
KMIP 어댑터에서 클라이언트 인증서 가져오기
KMIP 어댑터에서 클라이언트 인증서를 삭제합니다

작성자, 리더 및 ReaderPlus 역할은 KMIP 프로토콜에 액세스할 수 없습니다.

역할 및 Cloud Identity and Access Management 정책

Key Protect 콘솔에서는 해당 역할을 사용하여 사용자에게 세분화된 액세스 제어를 허용하는 한편, 해당 역할이 Cloud Identity and Access Management 정책에 연결되었음을 기억하는 데 도움이 될 수 있습니다.

• 서비스 이름(Key Protect의 경우 항상 kms)
• 서비스 인스턴스 ID
• 키 링 ID
• 리소스 유형(key만 지원됨)
• 리소스 ID
• 계정 ID(정책에 항상 지정되어야 함)

다음은 IAM API에서 리턴된 정책의 예입니다.

"resources": [
    {
        "attributes": [
            {
                "name": "accountId",
                "value": "$ACCOUNT_ID",
            },
            {
                "name": "serviceName",
                "value": "kms",
            },
            {
                "name": "resourceType",
                "value": "key",
            },
            {
                "name": "resource",
                "value": "$KEY_ID",
            },
            {
                "name": "keyRing",
                "value": "$KEY_RING_ID",
            }
        ]
    }
]

해당 속성의 조합을 정책에 적용할 수 있습니다. 해당 정책에 연결된 관리자 역할이 있으면, 이 정책이 적용된 모든 user/service id/access group은 권한이 부여된 정책의 하위 리소스에 적용되는 정책을 작성할 수 있습니다. 즉, 모든 하위 관리 사용자는 상위 관리자와 같거나(정책에 지정된 속성과 똑같은 속성) 낮은(지정된 정책 및 추가 속성에 지정된 속성과 똑같은 속성) 액세스 권한만 가질 수 있습니다.