이 페이지에서는 IAM 사용 시 유의해야 할 보안 권장사항을 설명합니다.
이 페이지는 Cloud IAM에 능숙한 사용자를 대상으로 합니다. 이 안내에서는 IAM 사용법을 설명하지 않으므로 IAM을 처음 시작하는 신규 사용자는 IAM 빠른 시작부터 대신 시작해야 합니다.
최소 권한
|
❑
모든 Google Cloud 서비스에서 기본 역할에는 수천 가지 권한이 포함됩니다. 프로덕션 환경에서는 대체 역할이 없는 경우가 아니라면 기본 역할을 부여하지 말아야 합니다. 대신 니즈를 충족하지만 가장 제한된 사전 정의된 역할이나 커스텀 역할을 부여합니다.
기본 역할을 바꿔야 하는 경우 역할 권장사항을 사용하여 대신 부여할 역할을 결정할 수 있습니다. 정책 시뮬레이터를 사용하여 역할을 변경해도 주 구성원의 액세스에 영향을 미치지 않도록 할 수 있습니다. 다음과 같은 경우에는 기본 역할을 부여하는 것이 적합할 수 있습니다.
|
|
❑
애플리케이션의 각 구성요소를 별도의 신뢰 경계로 취급합니다. 다양한 권한이 필요한 여러 가지 서비스가 있다면 서비스마다 별도의 서비스 계정을 생성한 다음 각 서비스 계정에 필요한 권한만 부여합니다.
|
|
❑
하위 리소스 허용 정책은 상위 리소스 허용 정책을 상속받습니다. 예를 들어 프로젝트 허용 정책이 사용자에게 Compute Engine 가상 머신(VM) 인스턴스를 관리할 수 있는 권한을 부여하면 사용자는 각 VM에 설정한 허용 정책에 관계없이 해당 프로젝트에서 모든 Compute Engine VM을 관리할 수 있습니다.
|
|
❑
필요한 최소 범위의 역할만 부여합니다. 예를 들어 사용자가 Pub/Sub 주제를 게시할 수 있는 권한만 필요로 하는 경우 사용자에게 해당 주제에 대한 게시자 역할을 부여합니다.
|
|
❑
서비스 계정으로 작업할 수 있는 주 구성원을 지정합니다.
서비스 계정에 대한 서비스 계정 사용자 역할을 부여받은 사용자는 서비스 계정이 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다. 따라서 사용자에게 서비스 계정 사용자 역할을 부여할 때는 주의해야 합니다.
|
|
❑
프로젝트에서 서비스 계정을 만들고 관리할 액세스 권한이 있는 사용자를 지정합니다.
|
|
❑
프로젝트 IAM 관리자 및 폴더 IAM 관리자에게 사전 정의된 역할을 부여하면 모든 리소스에 대한 직접적인 읽기, 쓰기, 관리 액세스를 허용하지 않고도 허용 정책을 수정할 수 있는 액세스 권한을 허용할 수 있습니다.
주 구성원에게 소유자( roles/owner) 역할을 부여하면 이 주 구성원은 허용 정책을 수정하는 것을 포함해 거의 모든 리소스에 액세스하여 수정할 수 있는 권한을 갖게 됩니다. 이렇게 큰 권한은 잠재적인 위험성이 있습니다. 거의 전역적인 액세스가 필요할 때만 소유자 역할을 부여하세요.
|
|
❑
조건부 역할 바인딩을 사용하여 액세스가 자동으로 만료되도록 하고 임시로 승격된 액세스 권한을 부여하는 것이 좋습니다.
|
서비스 계정
|
❑
서비스 계정 작업 권장사항을 채택합니다. 서비스 계정에 권한이 제한적인지 확인하고 잠재적인 보안 위협으로부터 보호합니다.
|
|
❑
실행 중인 인스턴스에서 사용 중인 서비스 계정을 삭제해서는 안 됩니다. 서비스 계정을 삭제하기 전에 먼저 다른 서비스 계정을 사용하도록 전환해야 합니다. 그렇지 않으면 애플리케이션의 일부 또는 전체가 작동하지 않을 수 있습니다.
|
|
❑
서비스 계정의 표시 이름을 사용하여 서비스 계정의 용도와 필요한 권한을 추적합니다.
|
서비스 계정 키
|
❑
다른 옵션을 사용할 수 있는 경우 서비스 계정 키를 사용하지 마세요.
서비스 계정 키를 올바르게 관리하지 않으면 보안 위험을 초래할 수 있습니다. 가능한 한 서비스 계정 키보다 안전한 대안을 선택해야 합니다. 서비스 계정 키로 인증해야 하는 경우 비공개 키와 서비스 계정 키 관리 권장사항에 설명된 기타 작업을 보호해야 합니다.
서비스 계정 키를 만들 수 없는 경우 서비스 계정 키 생성이 조직에 중지될 수 있습니다. 자세한 내용은 기본 보안별 조직 리소스 관리를 참조하세요.
|
|
❑
IAM 서비스 계정 API를 사용하여 서비스 계정 키를 순환합니다.
새 키를 만들고, 새 키를 사용하도록 애플리케이션을 전환하고, 이전 키를 사용 중지한 후, 이전 키가 더 이상 필요하지 않는지 확인되었을 때 삭제하는 방식으로 키를 순환할 수 있습니다.
|
|
❑
사용자 관리형 서비스 계정 키를 관리하는 프로세스를 구현합니다.
|
|
❑
암호화 키를 서비스 계정 키와 혼동하지 않도록 주의하세요. 암호화 키는 일반적으로 데이터를 암호화하는 데 사용되고, 서비스 계정 키는 Google Cloud API에 대한 보안 액세스에 사용됩니다.
|
|
❑
소스 코드에 서비스 계정 키를 추가하거나 이를 다운로드 디렉터리에 남겨두지 않도록 합니다.
|
감사
|
❑
Cloud 감사 로그의 로그를 사용하여 허용 정책의 변경사항을 정기적으로 감사합니다.
|
|
❑
Cloud Storage로 감사 로그를 내보내어 로그를 장기 보관합니다.
|
|
❑
프로젝트에 대한 허용 정책을 변경할 수 있는 권한이 있는 사람을 감사합니다.
|
|
❑
Logging 역할을 사용하여 로그에 대한 액세스를 관리합니다.
|
|
❑
로그 탐색기에 적용된 로그를 라우팅하는 데 사용하는 것과 동일한 액세스 정책을 Google Cloud 리소스에 적용합니다.
|
|
❑
Cloud 감사 로그의 로그를 사용하여 서비스 계정 키에 대한 액세스를 정기적으로 감사합니다.
|
정책 관리
|
❑
주 구성원이 조직의 모든 프로젝트에 액세스해야 할 경우 조직 수준에서 주 구성원에 역할을 부여합니다.
|
|
❑
가능하면 개별 사용자 대신 그룹에 역할을 부여합니다. 허용 정책에서 주 구성원을 업데이트하는 것보다 그룹의 구성원을 업데이트하는 것이 더 쉽습니다.
|