개발 및 배포 환경에 따라 AWS IAM 정책을 통합 자동화 하는 방법

AWS의 혁신 속도에 맞추기 위해 프로덕션 지원 아키텍처로 이동하는 많은 고객이 애플리케이션 팀을 통해 샌드박스 환경에서 AWS 서비스를 실험합니다. 이 과정에서 애플리케이션 팀은 다양한 AWS 서비스 세트에 적시에 액세스할 수 있어야 합니다. 따라서 최소 권한 부여를 보장할 수 있는 메커니즘도 필요합니다. 다시 말해, 일반적으로 애플리케이션 팀은 주기적인 Amazon Elastic Block Store 스냅샷 백업을 생성하는 AWS Lambda 함수 또는 보안 팀이 관리하는 중앙 정보 보안 계정으로 이벤트를 보내는 Amazon CloudWatch Events 규칙과 같은 관리 리소스에 액세스할 수 없어야 합니다.

이 블로그 게시물에서는 다양한 샌드박스, 개발 및 테스트 환경에서 작업하는 애플리케이션 팀에 대한 AWS Identity and Access Management(IAM) 정책을 생성하고 검증하는 중앙 집중식의 자동화된 워크플로를 생성하는 방법을 알려드립니다. 보안 개발자는 회사 보안 팀의 특정 요구 사항에 따라 이 워크플로를 사용자 지정할 수 있습니다. 또한 계정 유형 또는 담당 팀에 따라 허용되는 권한 세트를 제한하는 논리를 생성할 수 있습니다. 이 블로그 게시물에서는 AWS CodePipeline을 사용하여 다양한 단계를 포함하고 여러 AWS 계정에 걸쳐 있는 워크플로를 생성하고 관리합니다. 자세한 내용은 다음 섹션에서 설명합니다.

솔루션 개요

이 시나리오에서 Alice는 조직의 데이터 과학자가 Amazon Athena 및 Amazon EMR 같은 AWS 분석 서비스를 평가할 때 사용하는 AWS 샌드박스 계정의 관리자입니다. 데이터 과학자는 민감한 정보가 제거된 실제 데이터 세트의 일부에 샘플 분석 작업을 실행하여 프로덕션 사용 사례에 대한 이러한 서비스의 적합성을 평가합니다. 데이터 세트는 기존 Amazon Simple Storage Service(Amazon S3) 버킷에 저장됩니다. 새 프로젝트가 생길 때마다 Alice는 프로젝트 팀이 요청된 Amazon S3 버킷에 액세스하고 분석 클러스터를 생성하는 것을 허용하는 새 IAM 정책을 작성합니다. 그러나 Alice는 샌드박스 계정으로 특정 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 유형만 시작할 수 있어야 한다는 회사의 지침을 따라야 합니다. 또한 보안 팀이 샌드박스 계정의 규정 준수를 모니터링할 때 사용하는 모든 관리 AWS Lambda 함수 및 CloudWatch Events 규칙에 대한 액세스를 제한해야 합니다. 아래의 솔루션은 이러한 요구 사항을 충족하며 Alice를 비롯한 다른 관리자가 관리 작업을 손쉽게 수행할 수 있도록 합니다.

그림 1: 솔루션 아키텍처

Alice는 IAM 시각적 편집기를 사용하여 템플릿을 작성합니다. 데이터 과학자 팀은 이 템플릿에 액세스하여 S3 기반 데이터 세트를 분석하는 EMR 클러스터를 시작하고 관리할 수 있습니다. 그런 다음 Alice는 AWS Key Management Service(AWS KMS) 키를 사용하여IAM JSON 정책 문서를 기존 S3 버킷에 업로드합니다. 키 및 S3 버킷은 보안 팀이 계정 기준을 지정할 때 이미 생성되었습니다. 이 내용은 이 게시물의 뒷 부분에서 자세히 설명합니다.
AWS CodePipeline은 IAM JSON 정책 문서를 자동으로 가져오고, 보안 팀이 관리하는 AWS 계정에서 호스팅되는 중앙의 단일 Lambda 함수를 사용하는 일련의 검증 확인을 호출합니다.
IAM JSON 정책이 보안 개발자가 코딩한 모든 계정 및 일반적인 보안 요구 사항을 준수하면 중앙의 Lambda 함수가 Alice의 계정에 자동으로 정책을 생성하고 파이프라인은 성공합니다. 중앙의 검증 Lambda 함수는 미리 정의된 명시적 거부를 IAM 정책에 연결하여 샌드박스 계정의 불필요한 사용자 기능을 제한합니다. IAM JSON 정책이 확인에 실패하면 파이프라인이 실패하고 비준수에 대한 구체적인 이유가 Alice에게 제공됩니다. 이 경우 Alice는 정책을 수정하고 다시 제출해야 합니다. 정책이 성공적으로 생성되는 경우 Alice는 적합한 IAM 사용자, 그룹 또는 역할에 정책을 연결합니다.

솔루션 배포

이 솔루션에는 다음 세 가지 단계가 포함됩니다.

1단계: 솔루션 사전 조건 배포
2단계: 중앙 정보 보안 계정에 정책 검증 Lambda 함수 설정
3단계: 샌드박스 계정 파이프라인 테스트

사전 조건

이 솔루션은 AWS 서비스 또는 IAM 개체에 부여된 권한을 관리하므로 격리된 테스트 환경에서 솔루션을 먼저 테스트한 후 모든 보안 요구 사항을 충족하는지 확인하는 것이 좋습니다.

솔루션을 설정하려면 두 AWS 계정에 관리자로 액세스할 수 있어야 합니다. 이 솔루션의 배포는 일반적으로 조직의 관리자가 새로운 AWS 계정을 설정하는 동안 수행됩니다. 액세스해야 하는 두 가지 계정 유형은 다음과 같습니다.
- 샌드박스 계정. 애플리케이션 팀이 다양한 AWS 아키텍처를 실험할 때 사용하는 계정입니다. 이 계정은 앞서 언급했듯이 개발 또는 테스트 계정일 수 있습니다.
- 중앙 정보 보안 계정. 일반적으로 이 계정은 다중 계정 구조 내의 보안 규정 준수를 모니터링하고 시행하는 정보 보안 팀이 소유합니다.

중요: 정보 보안 계정에 생성하게 될 Lambda 함수에는 매우 높은 권한이 포함되므로 모범 사례에 따라 계정을 보호하는 것이 중요합니다. 계정 액세스를 보안 팀 멤버로 제한해야 합니다. 샌드박스 계정 관리자는 이 중앙의 Lambda 함수에 IAM 정책 생성을 제외한 샌드박스 계정의 어떠한 IAM 권한도 제공해서는 안 됩니다.

AWS Management Console을 두 AWS 계정에 사용할 것이므로 두 AWS 계정에 역할이 있어야 합니다. 콘솔의 Switch Role 기능을 사용하는 것이 좋습니다. 각 계정에 별칭을 연결하고 다른 색상 코드를 지정하면 언제든지 로그인한 계정을 알 수 있습니다.
이 솔루션에서 생성하는 모든 리소스에는 동일한 AWS 리전을 사용해야 합니다.

1단계: 솔루션 사전 조건 배포

두 AWS 계정에 대한 파이프라인을 구축하기 전에 IAM 역할 및 암호화 키 등의 필요한 리소스를 두 계정에 구성해야 합니다. 이 구성은 일반적으로 조직에서 샌드박스, 개발 또는 테스트 환경을 처음으로 설정할 때 보안 팀의 지침에 따라 수행됩니다.

중요

이 섹션에서 생성하게 될 초기 설정에 더해 보안 팀은 샌드박스, 개발 또는 테스트 계정 관리자가 해당 계정 유형에 대해 허용된 보안 정책을 충족하지 않는 IAM 정책(예: AdministratorAccess IAM 정책)을 연결하는 것을 명시적으로 거부해야 합니다. 또한 보안 팀은 계정의 현재 또는 향후 사용자, 그룹 또는 역할에 IAM 정책을 직접적으로 설정하거나 업데이트할 수 있는 권한(예: CreatePolicy, CreatePolicyVersion, PutRolePolicy, PutUserPolicy, PutGroupPolicy 또는 UpdateAssumeRolePolicy)이 없는지 확인해야 합니다. 권한 생성은 자동화 파이프라인을 통해서만 수행되어야 합니다. 파이프라인을 구축하는 방법은 곧 알려드릴 것입니다.

여기서 설명하는 솔루션은 최소 권한을 생성하는 데 중점을 두므로 보안 팀은 이 솔루션을 IAM 권한 경계와 함께 사용하여 이 솔루션에 정의된 권한의 범위를 조직의 모든 계정 유형에 대해 미리 정의된 권한 세트로 지정하는 것이 좋습니다. 예를 들어 계정 관리자는 IAM 사용자 또는 역할을 생성할 때 이러한 보안 주체에 연결되는 권한을 제한하는 미리 정의된 권한 경계 세트만 사용할 수 있습니다. 권한 경계에 대한 자세한 내용은 이 AWS 보안 블로그 게시물을 참조하십시오.

샌드박스 계정 사전 조건 생성

아래의 단계를 수행하여 샌드박스 계정에 다음 리소스를 생성할 AWS CloudFormation 템플릿을 배포합니다.

샌드박스 관리자가 IAM 정책을 업로드할 S3 버킷
자동화된 파이프라인이 IAM 정책이 저장된 S3 버킷에 액세스할 때 사용할 IAM 역할
S3 버킷의 IAM 정책을 암호화할 때 사용할 AWS KMS 키

기본 브라우저에서 샌드박스 계정에 로그인한 상태에서 이 링크를 선택하여 샌드박스 환경 사전 조건이 포함된 AWS 스택을 시작합니다. 그러면 템플릿 URL이 미리 입력된 CloudFormation 콘솔로 리디렉션됩니다.

그림 2: URL이 미리 입력된 CloudFormation 콘솔
[Next]를 선택하고 필요한 경우 스택 이름을 제공합니다. 제안된 스택 이름인 Sandbox-Prerequisites가 이미 입력되어 있습니다.
템플릿에 정의된 CentralAccount 입력 파라미터에 보안 계정의 AWS 계정 ID를 입력합니다. 보안 계정의 계정 ID를 찾는 방법에 대한 자세한 내용은 여기서 확인하십시오.
[Next]를 선택하고 [Next]를 다시 선택합니다.
파이프라인에 사용할 IAM 역할을 스택을 통해 생성하려면 [I acknowledge that AWS CloudFormation might create IAM resources with custom names] 확인란을 선택하고 [Create Stack]을 선택합니다.
[Stack info] 탭을 선택하고 [Stack Status] 필드 값을 주시하면서 주기적으로 새로 고칩니다. 스택이 [CREATE_COMPLETE] 상태가 되면 CloudFormation [Outputs] 탭으로 이동하고 다음 출력 값을 원하는 텍스트 편집기에 복사합니다. 이러한 값은 후속 CloudFormation 스택에서 사용됩니다.

그림 3: CloudFormation [Outputs] 탭

정보 보안 계정 사전 조건 생성

아래의 단계를 수행하여 정보 보안 계정에 다음 리소스를 생성할 CloudFormation 템플릿을 생성합니다.

자동화된 파이프라인에서 중앙의 Lambda 함수를 호출하고 샌드박스 계정 KMS 키에 대한 액세스를 제공할 때 사용할 IAM 역할
중앙의 Lambda 함수가 샌드박스 계정의 역할을 맡고 IAM 정책을 관리할 때 사용할 IAM 역할

기본 브라우저에서 보안 계정에 로그인한 상태에서 이 링크를 선택하여 보안 환경 사전 조건이 포함된 AWS 스택을 시작합니다. 그러면 템플릿 URL이 미리 입력된 CloudFormation 콘솔로 리디렉션됩니다.
[Next]를 선택하고 필요한 경우 스택 이름을 제공합니다. 제안된 스택 이름인 Sandbox-Prerequisites가 이미 입력되어 있습니다.
다음 입력 파라미터 필드를 입력합니다.
- SandboxAccount: 샌드박스 계정의 AWS 계정 ID
- ArtifactBucket: 샌드박스 계정에서 실행되는 이전 스택에서 텍스트 편집기에 기록한 버킷 이름
- CMKARN: 샌드박스 계정에서 실행되는 이전 스택에서 텍스트 편집기에 기록한 KMS 키의 ARN(Amazon 리소스 이름)
- PolicyCheckerFunctionName: 나중에 생성할 Lambda 함수의 이름. 기본값은 PolicyChecker입니다.
[Next]를 선택하고 [Next]를 다시 선택합니다.
파이프라인에 사용되는 IAM 역할을 스택을 통해 생성하려면 [I acknowledge that AWS CloudFormation might create IAM resources with custom names] 확인란을 선택하고 [Create Stack]을 선택합니다.
스택의 상태가 CREATE_COMPLETE가 될 때까지 기다립니다.

샌드박스 계정 파이프라인 생성

이제 샌드박스 계정으로 돌아가서 샌드박스 계정에 다음 리소스를 생성할 CloudFormation 템플릿을 배포합니다.

중앙 집중식 검증을 위해 S3에서 IAM 정책 문서를 가져와 보안 계정으로 전송하는 AWS CodePipeline 자동화 파이프라인. 유효한 경우 정보 보안 계정의 Lambda 함수가 샌드박스 계정에 IAM 정책을 생성합니다.
중앙의 Lambda 함수가 버킷의 IAM 정책 JSON 문서를 가져오는 것을 허용하는 S3 버킷 정책
중앙 정보 보안 계정의 Lambda 함수가 맡아 샌드박스 계정에 IAM 정책을 생성할 때 사용할 IAM 역할. 샌드박스 계정 관리자는 이러한 IAM 정책을 필요한 개체(예: IAM 사용자 또는 역할)에 연결할 수 있습니다.

기본 브라우저에서 샌드박스 계정에 로그인한 상태에서 이 링크를 선택하여 샌드박스 환경 사전 조건이 포함된 AWS 스택을 시작합니다. 그러면 템플릿 URL이 미리 입력된 CloudFormation 콘솔로 리디렉션됩니다.
[Next]를 클릭하고 필요한 경우 스택 이름을 제공합니다. 제안된 스택 이름인 Sandbox-Pipeline이 이미 입력되어 있습니다.
다음 입력 파라미터 필드를 입력합니다.
- CentralAccount: 정보 보안 계정의 AWS 계정 ID(하이픈 없음)
- ArtifactBucket: 앞서 텍스트 편집기에서 기록하여 정보 보안 계정의 이전 스택에 사용한 버킷 이름
- CMKARN: 앞서 텍스트 편집기에서 기록하여 정보 보안 계정의 이전 스택에 사용한 KMS 키의 ARN
- PolicyCheckerFunctionName: 나중에 생성할 Lambda 함수의 이름. 정보 보안 계정 템플릿에 제공한 것과 동일한 값이어야 합니다.
[Next]를 선택하고 [Next]를 다시 선택합니다.
필요한 IAM 역할을 스택을 통해 생성하려면 [I acknowledge that AWS CloudFormation might create IAM resources with custom names] 확인란을 선택하고 [Create Stack]을 선택합니다.
스택의 상태가 CREATE_COMPLETE가 될 때까지 기다립니다.

2단계: 중앙 정보 보안 계정에 정책 검증 Lambda 함수 설정

중앙 정보 보안 계정에서 샌드박스 환경에서 생성된 IAM 정책을 검증하는 Lambda 함수를 생성합니다.

AWS Lambda 콘솔에서 [Create Function]을 선택하고 [Author from scratch]를 선택합니다. 다음 필드에 대한 값을 제공합니다.

Name. 1단계에서 정보 보안 계정 사전 조건을 설정할 때 CloudFormation에 대한 PolicyCheckerFunctionName 입력 파라미터로 정의한 함수 이름과 같은 이름이어야 합니다. 1단계에서 기본값을 변경하지 않은 경우 기본값은 여전히 PolicyChecker입니다.
Runtime. Python 2.7.
Role. 역할을 설정하려면 [Choose an existing role]을 선택하고 이름이 policy-checker-lambda-role인 역할을 선택합니다. 이 역할은 1단계에서 정보 보안 계정 사전 조건을 설정할 때 생성한 역할입니다.

[Create Function]을 선택하고 [Function Code]로 아래로 스크롤한 후 다음 코드를 편집기에 붙여 넣습니다(기존 코드 대체).


#  Copyright 2017 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#  Licensed under the Apache License, Version 2.0 (the "License"). You may not
#  use this file except in compliance with
#  the License. A copy of the License is located at
#      http://thinkwithwp.com/apache2.0/
#  or in the "license" file accompanying this file. This file is distributed
#  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
#  either express or implied. See the License for the
#  specific language governing permissions and
#  limitations under the License.
from __future__ import print_function
import json
import boto3
import zipfile
import tempfile
import os

print('Loading function')
PERMISSIVE_ERROR_MSG = """Policy creation request rejected: * permissions not
                         allowed in both actions and resources"""
GENERAL_ERROR_MSG = """An error has occurred while validating policy.
                        Please contact admin"""


def get_template(event, s3, artifact, file_in_zip):
    tmp_file = tempfile.NamedTemporaryFile()
    bucket = event['CodePipeline.job']['data']['inputArtifacts'][0]['location']['s3Location']['bucketName']
    key = event['CodePipeline.job']['data']['inputArtifacts'][0]['location']['s3Location']['objectKey']

    with tempfile.NamedTemporaryFile() as tmp_file:
        s3.download_file(bucket, key, tmp_file.name)
        with zipfile.ZipFile(tmp_file.name, 'r') as zip:
            return zip.read(file_in_zip)


def get_sts_session(event, account, rolename):
    sts = boto3.client("sts")
    RoleArn = str("arn:aws:iam::" + account + ":role/" + rolename)
    response = sts.assume_role(
        RoleArn=RoleArn,
        RoleSessionName='SecurityManageAccountPermissions',
        DurationSeconds=900)
    sts_session = boto3.Session(
        aws_access_key_id=response['Credentials']['AccessKeyId'],
        aws_secret_access_key=response['Credentials']['SecretAccessKey'],
        aws_session_token=response['Credentials']['SessionToken'],
        region_name=os.environ['AWS_REGION'],
        botocore_session=None,
        profile_name=None)
    return (sts_session)


def ManagePolicy(event, context):
    # Set boto session to get pipeline artifact from sandbox/dev/test account
    artifact_session = boto3.Session(
        aws_access_key_id=event['CodePipeline.job']['data']
                               ['artifactCredentials']['accessKeyId'],
        aws_secret_access_key=event['CodePipeline.job']['data']
                                   ['artifactCredentials']['secretAccessKey'],
        aws_session_token=event['CodePipeline.job']['data']
                               ['artifactCredentials']['sessionToken'],
        region_name=os.environ['AWS_REGION'],
        botocore_session=None,
        profile_name=None)
    # Fetch pipeline artifact from S3
    s3 = artifact_session.client('s3')
    permission_doc = get_template(event, s3, '', 'policy.json')
    metadata_doc = json.loads(get_template(event, s3, '', 'metadata.json'))
    permission_doc_json = json.loads(permission_doc)
    # Assume the central account role in sandbox/dev/test account
    global STS_SESSION
    STS_SESSION = ''  
    STS_SESSION = get_sts_session(
        event, event['CodePipeline.job']['accountId'], 'central-account-role')
    iam = STS_SESSION.client('iam')
    codepipeline = STS_SESSION.client('codepipeline')
    policy_arn = 'arn:aws:iam::' + event['CodePipeline.job']['accountId'] + ':policy/' + metadata_doc['PolicyName']

    try:
        # 1.Sample code - Validate policy sent from sandbox/dev/test account:
        # look for * actions and * resources
        for statement in permission_doc_json['Statement']:
            if statement['Action'] == '*' and statement['Resource'] == '*':
                return codepipeline.put_job_failure_result(
                                    jobId=event['CodePipeline.job']['id'],
                                    failureDetails={
                                        'type': 'JobFailed',
                                        'message': PERMISSIVE_ERROR_MSG})
        # 2.Sample code - Attach any required denies from central
        # pre-defined policy
        iam_local = boto3.client('iam')
        account_id = context.invoked_function_arn.split(":")[4]
        local_policy_arn = 'arn:aws:iam::' + account_id + ':policy/central-deny-policy-sandbox'
        policy_response = iam_local.get_policy(PolicyArn=local_policy_arn)
        policy_version_id = policy_response['Policy']['DefaultVersionId']
        policy_version_doc = iam_local.get_policy_version(
            PolicyArn=local_policy_arn,
            VersionId=policy_version_id)
        for statement in policy_version_doc['PolicyVersion']['Document']['Statement']:
            permission_doc_json['Statement'].append(
               statement
            )
        # 3. If validated successfully, create policy in
        # sandbox/dev/test account
        iam.create_policy(
            PolicyName=metadata_doc['PolicyName'],
            PolicyDocument=json.dumps(permission_doc_json),
            Description=metadata_doc['PolicyDescription'])

        # successful creation, put result back to
        # sandbox/dev/test account pipeline
        codepipeline.put_job_success_result(
            jobId=event['CodePipeline.job']['id'])
    except Exception as e:
        print('Error: ' + str(e))
        codepipeline.put_job_failure_result(
            jobId=event['CodePipeline.job']['id'],
            failureDetails={'type': 'JobFailed', 'message': GENERAL_ERROR_MSG})

def lambda_handler(event, context):
    print(event)
    ManagePolicy(event, context)

이 샘플 코드에서 Lambda 함수는 Alice가 제출한 IAM JSON 정책이 모든 계정 리소스에 대한 모든 IAM 작업을 허용하는, 지나치게 많은 권한을 허용하는 정책인지 여부를 확인합니다. 또한 이 샘플 코드에는 T2 EC2 인스턴스 패밀리의 일부가 아닌 Amazon EC2 인스턴스의 시작을 차단하는 IAM Deny 작업이 나와 있습니다. 이 명시적 거부는 T2 인스턴스만 시작될 수 있도록 합니다. 보안 개발자는 이 샘플 코드와 유사한 코드를 작성하여 모든 계정 유형의 보안 정책을 충족하고 다양한 샌드박스, 개발 및 테스트 환경에서 생성되는 IAM 정책을 제어해야 합니다.

새 Lambda 함수 코드를 저장하기 전에 [Basic Settings] 섹션까지 아래로 스크롤한 다음 함수 제한 시간을 10초로 늘립니다.
[Save]를 선택합니다.

3단계: 샌드박스 계정 파이프라인 테스트

이제 샌드박스 계정에 솔루션을 배포할 준비가 되었습니다.

다음 파일을 생성하고 이름이 policy.zip인 아카이브(생성한 파이프라인에 지정된 이름)로 압축합니다.

metadata.json: 이 파일에는 생성할 IAM 정책의 이름 및 설명 같은 메타데이터가 포함됩니다.


                {
                "PolicyDescription": "ec2 start permission policy",
                "PolicyName": "Ec2RunTeamA"
                }

policy.json: 이 파일에는 생성할 IAM 정책의 JSON 본문이 포함됩니다.


                {
                "Version": "2012-10-17",
                "Statement": [
                        {
                        "Sid": "EC2Run",
                        "Effect": "Allow",
                        "Action": "ec2:RunInstances",
                        "Resource": "*"
                        }
                ]
                }

policy.zip 파일을 앞서 생성한 버킷에 업로드하려면 샌드박스 계정의 Amazon S3 콘솔로 이동하고 페이지 맨 위의 검색 상자를 사용하여 앞서 텍스트 편집기에서 ArtifactBucket로 기록한 버킷을 검색합니다.
버킷을 찾으면 버킷 이름을 선택하고 [Upload]를 선택합니다. 업로드 대화 상자가 나타납니다.
[Add Files]를 선택하고 policy.zip 파일이 있는 폴더로 이동합니다. 파일을 선택하고 [Open]을 선택한 다음 [Next]를 선택하고 다시 [Next]를 선택합니다.

그림 4: S3 업로드 대화 상자
[AWS KMS master-key] 라디오 버튼을 선택한 다음 별칭이 codepipeline-policy-crossaccounts인 KMS 키를 선택합니다.

그림 5: KMS 키 선택
[Next]를 선택하고 [Upload]를 선택합니다.
AWS CodePipeline 콘솔로 이동하고 샌드박스 파이프라인을 선택한 다음 파이프라인이 실행될 때까지 기다립니다. 시작되기까지 최대 1분이 소요될 수 있습니다.

그림 6: AWS CodePipeline 콘솔
파이프라인이 완료될 때까지 기다립니다. 방금 업로드한 IAM 정책에 검증 오류가 없어야 하며 IAM 정책이 성공적으로 생성되어야 합니다. 새로 생성된 IAM 정책을 보려면 AWS IAM 콘솔을 엽니다.
왼쪽에서 [Policies]를 선택하고 metadata.json 파일에 정의된 이름을 사용하여 정책을 검색합니다.

그림 7: 새 정책 보기
정책 이름을 선택합니다. 정의한 정책에 IAM deny가 자동으로 추가된 것을 알 수 있습니다.

파이프라인을 추가로 테스트하려는 경우 모든 리소스에 대한 모든 작업을 허용하도록 정책을 수정할 수 있습니다. policy.zip이 다시 업로드되면 파이프라인이 다음 오류를 반환해야 합니다.


Policy creation request rejected: * permissions not allowed in both actions and resources

Lambda 함수 코드를 수정할 때 오류가 발생하면 언제든지 중앙 정보 보안 계정의 Lambda 함수 로그로 돌아갈 수 있습니다. Lambda 함수 로그에 액세스하는 방법에 대한 자세한 내용은 설명서를 참조하십시오.

여기에 사용된 동일한 논리를 다른 샌드박스, 개발 또는 테스트 환경으로 확장할 수 있습니다. 그러나 중앙 정보 보안 계정의 경우 새로 추가된 샌드박스, 개발 또는 테스트 계정의 리소스를 신뢰하고 이러한 리소스에 액세스할 수 있도록 기존 역할을 업데이트해야 합니다.

요약

이 블로그 게시물에서는 다양한 AWS 계정에 대한 IAM 정책의 검증 및 생성을 중앙 집중화하는 방법을 살펴봤습니다. 보안 개발자는 이 방법을 사용하여 보안 모범 사례를 코딩하고, 다양한 샌드박스, 개발 및 테스트 계정에 대한 IAM 정책의 생성 및 검증을 자동화할 수 있습니다. 계정 관리자는 이 검증된 IAM 정책을 필요한 IAM 사용자, 그룹 또는 역할에 연결할 수 있습니다. 이 프로세스는 민첩성과 제어 사이의 균형을 유지합니다. 계정 관리자는 규정을 준수하는 최소 권한의 IAM 정책을 생성할 수 있으며 애플리케이션 팀은 실험 및 혁신을 가속화할 수 있습니다. 이 블로그 게시물에 대한 피드백이 있는 경우 아래의 댓글 섹션에 제출해 주십시오.

AWS 보안의 방법 콘텐츠, 뉴스 및 기능 발표에 대한 내용이 궁금하십니까? Twitter에서 AWS를 팔로우하십시오.

작성자 사진 Mahmoud ElZayet는 AWS의 글로벌 어카운트 솔루션스 아키텍트입니다. 대규모 엔터프라이즈 고객과 함께 일하면서 클라우드 솔루션 구축에 필요한 지침과 기술 지원을 제공합니다. Mahmoud 씨는 DevOps 및 클라우드 규정 준수에 관심이 많습니다. 휴일에는 아내와 두 자녀와 함께 새로운 장소를 찾아다니는 것을 좋아합니다.

이 글은 AWS Security 블로그 How to centralize and automate IAM policy creation in sandbox, development, and test environments의 한국어 번역입니다.

Amazon Web Services 한국 블로그