정보를 사용하여 IAM 그룹의 권한 축소 정보를 사용하여 IAM 사용자의 사용 권한 축소 IAM 리소스를 삭제하기 전에 정보 사용 IAM 정책을 편집하기 전에 정보 사용 기타 IAM 시나리오 정보를 사용하여 조직 단위의 권한 재정의

마지막으로 액세스한 정보 사용에 대한 예제 시나리오

마지막으로 액세스한 정보를 사용하여 IAM 엔터티 또는 AWS Organizations 엔터티에 부여할 권한을 결정할 수 있습니다. 자세한 내용은 마지막으로 액세스한 정보를 사용하여 AWS에서의 권한 재정의 섹션을 참조하세요.

참고

IAM 또는 AWS Organizations의 엔터티 또는 정책에 대한 액세스 정보를 보려면 먼저 보고 기간, 보고된 엔터티 및 데이터에 대해 평가된 정책 유형을 이해해야 합니다. 자세한 내용은 마지막으로 액세스한 정보에 대해 알아야 할 사항 단원을 참조하세요.

회사에 적합한 액세스 가능성과 최소 권한 간에 적절한 균형을 유지하는 것은 관리자에게 달려 있습니다.

정보를 사용하여 IAM 그룹의 권한 축소

마지막으로 액세스한 정보를 사용하여 사용자에게 필요한 서비스만 포함하도록 IAM 그룹 권한을 축소할 수 있습니다. 이 방법은 서비스 수준에서 최소 권한을 부여하는 데 있어 중요한 단계입니다.

예를 들어, Paulo Santos는 Example Corp에 대한 AWS 사용자 권한 정의를 담당하는 관리자입니다. 이 회사는 이제 막 AWS 사용을 시작했으며 소프트웨어 개발 팀은 아직 어떤 AWS 서비스를 사용할지 정의하지 않았습니다. Paulo는 팀에게 필요한 서비스에만 액세스할 수 있는 권한을 부여하려고 하지만, 아직 정의되지 않았기 때문에 일시적으로 파워 사용자 권한을 부여합니다. 그런 다음 마지막으로 액세스한 정보를 사용하여 그룹 권한을 축소합니다.

Paulo는 다음 JSON 텍스트를 사용하여 ExampleDevelopment 관리 정책을 만듭니다. 그런 다음 이 정책을 Development 그룹에 연결하고 모든 개발자를 그룹에 추가합니다.

참고

Paulo의 고급 사용자가 일부 서비스 및 기능을 사용하려면 iam:CreateServiceLinkedRole 권한이 필요할 수 있습니다. 이 권한을 추가하면 사용자가 서비스 연결 역할을 생성할 수 있게 됩니다. Paulo는 파워 사용자에 대한 이 위험을 수락합니다.


{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToAllServicesExceptPeopleManagement",
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Paulo는 90일 후에 AWS Management Console을 사용하여 Development 그룹에 대해 서비스에서 마지막으로 액세스한 정보를 보기로 결정합니다. 그는 그룹 멤버가 액세스한 서비스 목록을 확인합니다. 그는 사용자가 지난주에 5개의 서비스, 즉 AWS CloudTrail, Amazon CloudWatch Logs, Amazon EC2, AWS KMS 및 Amazon S3에 액세스했다는 사실을 알게 되었습니다. 그들은 AWS를 처음 평가할 때 몇 가지 다른 서비스에 액세스했지만 그 이후에는 액세스하지 않았습니다.

Paulo는 5가지 서비스와 필요한 IAM 및 조직 작업만 포함하도록 정책 권한을 줄이기로 합니다. 그는 다음 JSON 텍스트를 사용하여 ExampleDevelopment 정책을 편집합니다.

참고


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToListedServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "kms:*",
                "cloudtrail:*",
                "logs:*",
                "ec2:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

권한을 더 줄이기 위해 Paulo는 AWS CloudTrail 이벤트 기록에서 계정의 이벤트를 확인할 수 있습니다. 여기서 그는 개발자가 필요로 하는 작업과 리소스만 포함하도록 정책 권한을 줄이기 위해 사용할 수 있는 자세한 이벤트 정보를 볼 수 있습니다. 자세한 내용은 AWS CloudTrail 사용 설명서의 CloudTrail 콘솔에서 CloudTrail 이벤트 보기를 참조하세요.

정보를 사용하여 IAM 사용자의 사용 권한 축소

마지막으로 액세스한 정보를 사용하여 개별 IAM 사용자의 권한을 축소할 수 있습니다.

예를 들어 Martha Rivera는 회사 직원들의 AWS 권한이 초과되지 않도록 관리하는 IT 관리자입니다. 정기 보안 검사의 일환으로 Martha는 모든 IAM 사용자의 권한을 검토합니다. 이러한 사용자 가운데는 애플리케이션 개발자로, 이전에 보안 엔지니어의 역할을 담당했던 Nikhil Jayashankar 씨도 있습니다. 작업 요구 사항의 변화로 인해 Nikhil은 app-dev 그룹과 security-team 그룹의 멤버입니다. 새로운 직무와 관련된 app-dev 그룹은 Amazon EC2, Amazon EBS, Auto Scaling, Amazon S3, Route 53 및 Elastic Transcoder를 포함한 여러 서비스에 대한 권한을 부여합니다. 이전 직무와 관련된 security-team 그룹은 IAM 및 CloudTrail에 대한 권한을 부여합니다.

관리자인 Martha는 IAM 콘솔에 로그인하고 사용자(Users)를 선택한 다음 nikhilj 이름을 선택하고 액세스 관리자(Access Advisor) 탭을 선택합니다.

Martha는 마지막 액세스 열을 검토하여 Nikhil이 최근에 IAM, CloudTrail, Route 53, Amazon Elastic Transcoder 및 기타 여러 AWS 서비스에 액세스하지 않았다는 것을 확인합니다. Nikhil은 Amazon S3 액세스했습니다. Martha는 서비스 목록에서 S3를 선택하여 Nikhil이 지난 2주 동안 일부 S3 List 작업을 수행했음을 알게 됩니다. 회사 내에서 Martha는 Nikhil이 더 이상 내부 보안 팀의 멤버가 아니므로 업무적으로 IAM 및 CloudTrail에 액세스할 필요가 없다는 것을 확인합니다.

Martha는 이제 마지막으로 액세스한 서비스 및 작업 정보에 대해 조치를 취할 준비가 되었습니다. 그러나 이전 예제의 그룹과 달리 nikhilj과 같은 IAM 사용자는 여러 정책을 준수하고 여러 그룹의 멤버가 될 수 있습니다. Martha는 nikhilj 또는 다른 그룹 멤버의 액세스를 실수로 방해하지 않도록 주의해서 진행해야 합니다. Nikhil에게 부여할 액세스 권한의 종류뿐만 아니라, 이러한 권한을 받는 방법을 결정해야 합니다.

Martha는 권한 탭을 선택합니다. 이 탭에서 nikhilj에 직접 연결된 정책 및 그룹을 통해 연결된 정책을 확인합니다. 그녀는 각 정책을 확장하고 Nikhil이 사용하지 않는 서비스에 대한 액세스를 허용하는 정책을 알아보기 위해 정책 요약을 확인합니다.

IAM - IAMFullAccess AWS 관리형 정책은 nikhilj에 직접 연결되고 security-team 그룹에 연결됩니다.
CloudTrail - AWSCloudTrailReadOnlyAccess AWS 관리형 정책은 security-team 그룹에 연결됩니다.
Route 53 - App-Dev-Route53 고객 관리형 정책은 app-dev 그룹에 연결됩니다.
Elastic Transcoder - App-Dev-ElasticTranscoder 고객 관리형 정책은 app-dev 그룹에 연결됩니다.

Martha는 nikhilj에 직접 연결된 IAMFullAccess AWS 관리형 정책을 제거하기로 결정했습니다. 또한 security-team 그룹에 대한 Nikhil의 멤버십을 제거합니다. 이 두 작업은 IAM 및 CloudTrail에 대한 불필요한 액세스를 제거합니다.

Route 53 및 Elastic Transcoder에 액세스할 수 있는 Nikhil의 권한은 app-dev 그룹에 의해 부여됩니다. Nikhil은 이러한 서비스를 사용하지 않지만 그룹의 다른 멤버에게는 필요할 수 있습니다. Martha는 app-dev 그룹에 대해 마지막으로 액세스한 정보를 검토하고 여러 멤버가 최근에 Route 53 및 Amazon S3에 액세스했음을 알게 됩니다. 그러나 작년에는 Elastic Transcoder에 액세스한 멤버가 없습니다. 그녀는 그룹에서 App-Dev-ElasticTranscoder 고객 관리형 정책을 제거합니다.

그런 다음 Martha는 고객 관리형 정책인 App-Dev-ElasticTranscoder에 대해 마지막으로 액세스한 정보를 검토합니다. 그녀는 정책이 다른 IAM 자격 증명에 연결되지 않았다는 것을 알게 됩니다. 그녀는 회사 내에서 앞으로 해당 정책이 필요하지 않다는 것을 조사한 다음 삭제합니다.

IAM 리소스를 삭제하기 전에 정보 사용

IAM 리소스를 삭제하기 전에 마지막으로 액세스한 정보를 사용하여 마지막으로 리소스를 사용한 이후로 일정 시간이 경과했는지 확인할 수 있습니다. 이는 사용자, 그룹, 역할 및 정책에 적용됩니다. 이러한 작업에 대한 자세한 내용은 다음 주제를 참조하세요.

IAM 정책을 편집하기 전에 정보 사용

해당 리소스에 영향을 미치는 정책을 편집하기 전에 IAM 자격 증명(사용자, 그룹 또는 역할) 또는 IAM 정책에 대해 마지막으로 액세스한 정보를 검토할 수 있습니다. 이 기능은 사용 중인 사용자의 액세스 권한을 제거하지 않으려는 경우 중요합니다.

예를 들어, Arnav Desai는 Example Corp의 개발자이자 AWS 관리자입니다. 그의 팀이 AWS를 사용하기 시작하여 모든 개발자에게 IAM 및 Organizations를 제외한 모든 서비스에 대한 완전한 액세스를 허용하는 고급 사용자 권한을 부여했습니다. Arnav는 최소 권한 부여를 위한 첫 걸음으로 AWS CLI를 사용하여 자신의 계정에서 관리형 정책을 검토하려고 합니다.

이렇게 하기 위해 Arnav는 먼저 다음 명령을 사용하여 자격 증명에 연결된 계정에 고객 관리형 권한 정책을 나열합니다.


aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy

응답에서 그는 각 정책에 대한 ARN을 캡처합니다. 그런 다음 Arnav는 다음 명령을 사용하여 각 정책에 대해 마지막으로 액세스한 정보 보고서를 생성합니다.


aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1

이 응답에서 그는 JobId 필드에서 생성된 보고서의 ID를 캡처합니다. 그런 다음 Arnav는 JobStatus 필드가 COMPLETED 또는 FAILED 값을 반환할 때까지 다음 명령을 폴링합니다. 작업이 실패할 경우 오류를 캡처합니다.


aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9

작업의 상태가 COMPLETED이면 Arnav는 JSON 형식의 ServicesLastAccessed 배열에 대한 콘텐츠를 구문 분석합니다.


 "ServicesLastAccessed": [
        {
            "TotalAuthenticatedEntities": 1,
            "LastAuthenticated": 2018-11-01T21:24:33.222Z,
            "ServiceNamespace": "dynamodb",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser",
            "ServiceName": "Amazon DynamoDB"
        },

        {
            "TotalAuthenticatedEntities": 0,
            "ServiceNamespace": "ec2",
            "ServiceName": "Amazon EC2"
        },

        {
            "TotalAuthenticatedEntities": 3,
            "LastAuthenticated": 2018-08-25T15:29:51.156Z,
            "ServiceNamespace": "s3",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole",
            "ServiceName": "Amazon S3"
        }
    ]

이 정보를 통해 Arnav는 ExamplePolicy1 정책이 Amazon DynamoDB, Amazon S3 및 Amazon EC2의 세 가지 서비스에 대한 액세스를 허용한다는 것을 알게 됩니다. 11월 1일 IAM 사용자 IAMExampleUser가 DynamoDB에 마지막으로 액세스하려고 시도했으며, 8월 25일에는 어떤 사용자가 Amazon S3에 액세스하기 위해 IAMExampleRole 역할을 사용했습니다. 작년에 Amazon S3에 액세스하려고 시도한 엔터티가 두 개 더 있습니다. 그러나 작년에 Amazon EC2에 액세스하려고 시도한 사용자는 아무도 없었습니다.

이는 Arnav가 정책에서 Amazon EC2 작업을 안전하게 제거할 수 있음을 의미합니다. Arnav는 정책에 대한 현재 JSON 문서를 검토하려고 합니다. 먼저, 다음 명령을 사용하여 정책의 버전 번호를 결정해야 합니다.


aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1

응답에서 Arnav는 Versions 배열에서 현재 기본 버전 번호를 수집합니다. 그런 다음, 다음 명령을 통해 해당 버전 번호(v2)를 사용하여 JSON 정책 문서를 요청합니다.


aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2

Arnav는 반환된 JSON 정책 문서를 PolicyVersion 배열의 Document 필드에 저장합니다. 정책 문서에서 Arnav는 ec2 네임스페이스에서 작업을 검색합니다. 정책에 남아 있는 다른 네임스페이스의 작업이 없는 경우 영향을 받는 자격 증명(사용자, 그룹 및 역할)에서 정책을 분리합니다. 그런 다음 정책을 삭제합니다. 이 경우, 정책에는 Amazon DynamoDB 및 Amazon S3 서비스가 포함됩니다. 그래서 Arnav는 문서에서 Amazon EC2 작업을 제거하고 변경 사항을 저장합니다. 그는 다음 명령을 사용하여 새 버전의 문서를 통해 정책을 업데이트하고 해당 버전을 기본 정책 버전으로 설정합니다.


aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default

이제 ExamplePolicy1 정책이 업데이트되어 불필요한 Amazon EC2 서비스에 대한 액세스를 제거합니다.

기타 IAM 시나리오

IAM 리소스(사용자, 그룹, 역할 또는 정책)가 서비스에 마지막으로 액세스하려고 시도한 시점에 대한 정보는 다음 작업 중 하나를 완료할 때 도움이 될 수 있습니다.

정책 - 기존 고객 관리형 또는 인라인 정책을 편집하여 권한 제거
정책 - 인라인 정책을 관리형 정책으로 변환한 다음 삭제
정책 - 기존 정책에 명시적 거부 추가
정책 - 자격 증명(사용자, 그룹 또는 역할)에서 관리형 정책 분리
엔터티 - 엔터티(사용자 또는 역할)가 가질 수 있는 최대 권한을 제어하도록 권한 경계 설정
그룹 - 그룹에서 사용자 제거

정보를 사용하여 조직 단위의 권한 재정의

마지막으로 액세스한 정보를 사용하여 AWS Organizations의 조직 단위(OU)의 권한을 재정의할 수 있습니다.

예를 들어 John Stiles는 AWS Organizations 관리자입니다. 그는 회사 AWS 계정의 사람들에게 과도한 권한이 부여되지 않도록 할 책임이 있습니다. 정기 보안 검사의 일환으로 그는 자신의 조직에 부여된 권한을 검토합니다. 그의 Development OU에는 새로운 AWS 서비스를 테스트하는 데 자주 사용되는 계정이 포함되어 있습니다. John은 180일 이상 액세스되지 않은 서비스에 대한 보고서를 주기적으로 검토하기로 결정합니다. 그런 다음 OU 멤버가 이러한 서비스에 액세스할 수 있는 권한을 제거합니다.

John은 자신의 관리 계정 자격 증명을 사용하여 IAM 콘솔에 로그인합니다. IAM 콘솔에서 Development OU에 대한 조직 데이터를 찾습니다. 그는 서비스 액세스 보고서 표를 검토하여 180일 이상 액세스되지 않은 2개의 AWS 서비스를 발견합니다. 그는 개발 팀이 Amazon Lex 및 AWS Database Migration Service에 액세스할 수 있는 권한을 추가한 것을 기억합니다. 그래서 개발 팀에 연락하여 더 이상 이러한 서비스를 테스트할 업무상 필요가 없는지 확인합니다.

John은 이제 마지막으로 액세스한 정보에 대해 조치를 취할 준비가 되었습니다. 그는 AWS Organizations에서 편집을 선택합니다. 그러면 이 SCP가 여러 엔터티에 연결되어 있다는 메시지가 표시됩니다. 계속을 선택합니다. 그는 AWS Organizations에서 대상을 검토하여 SCP에 어떤 조직 엔터티가 연결되어 있는지 확인합니다. 모든 엔터티가 Development OU에 속해 있습니다.

John은 NewServiceTest SCP에서 Amazon Lex 및 AWS Database Migration Service 작업에 대한 액세스를 거부하기로 합니다. 이 작업은 서비스에 대한 불필요한 액세스 권한을 제거합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Organizations에 대한 액세스 정보 보기

작업에서 마지막으로 액세스한 정보와 관련된 서비스 및 작업