サンドボックス、開発、テスト環境で IAM ポリシー作成を一元化および自動化する方法

本番環境に対応したアーキテクチャに移行する際、お客様のアプリケーションチームはサンドボックス環境で AWS のサービスを試して、AWS の進化していくイノベーションに対応することができます。アプリケーションチームは、さまざまな AWS のサービスとリソースにタイムリーにアクセスする必要があります。つまり、最低限の権限を与えられることを保証するメカニズムを必要とします。通常、アプリケーションチームは、定期的に Amazon Elastic Block Store のスナップショットバックアップを行う AWS Lambda 関数や、セキュリティチームが管理する一元化された情報セキュリティアカウントにイベントを送信する Amazon CloudWatch Events ルールなどの管理リソースにアクセスできません。

このブログ投稿では、さまざまなサンドボックス、開発、テスト環境で作業しているアプリケーションチームが AWS Identity and Access Management (IAM) ポリシーを作成および検証するため、一元化かつ自動化したワークフローを作成する方法をご紹介します。セキュリティ開発者は、セキュリティチームの特定の要件に従ってこのワークフローをカスタマイズできます。セキュリティ開発者は、アカウントの種類または所有チームに基づいたアクセス許可セットを制限するロジックも作成できます。AWS CodePipeline を使用して、さまざまな段階や複数の AWS アカウントにわたるワークフローを作成および管理します。これについては、次のセクションで詳しく説明します。

ソリューションの概要

次のシナリオから始めましょう。Alice は AWS サンドボックスアカウントの管理者です。これは、組織のデータサイエンティストが Amazon Athena や Amazon EMR などの AWS の分析サービスを試す際に使用します。データサイエンティストは、機密情報が取り出された後、実際のデータセットの一部に対して分析ジョブのサンプルを実行することで、これらのサービスが本番ユースケースに適合しているかを評価します。データセットは既存の Amazon Simple Storage Service (Amazon S3) バケットに保存されます。Alice は新しいプロジェクトごとに、プロジェクトチームに要求された Amazon S3 バケットにアクセスして、分析クラスターを作成できるようにする新しい IAM ポリシーを作成します。ただし Alice は、サンドボックスアカウントが特定の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプのみを起動できるという会社のガイドラインに従う必要があります。さらに、セキュリティチームがサンドボックスアカウントのコンプライアンスをモニタリングするのに使用する、すべての管理上の AWS Lambda 機能と CloudWatch Events ルールへのアクセスを制限する必要もあります。以下に示すのは、これらの要件を満たし、Alice や他の管理者がタスクの実行を簡単にできるようにするソリューションです。

ソリューションのアーキテクチャ

Alice は IAM ビジュアルエディタを使用して、データサイエンスチームが EMR クラスターを起動および管理するためのアクセスを許可するテンプレートを作成します。このクラスターは S3 ベースのデータセットを分析するものです。次に、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 ユーザー、グループ、またはロールに添付します。

ソリューションのデプロイメント

このソリューションには、次の 3 つの手順が含まれます。

ステップ 1: ソリューションの前提条件をデプロイする
ステップ 2: 中央の情報セキュリティアカウントでポリシーを検証する Lambda 関数を設定する
ステップ 3: サンドボックスアカウントのパイプラインをテストする

前提条件

このソリューションでは AWS のサービスまたは IAM エンティティに付与されるアクセス許可を管理するため、最初に隔離されたテスト環境でソリューションを試し、セキュリティ要件をすべて満たしていることを確認することを強く推奨します。

ソリューションをセットアップするには、2 つの AWS アカウントで管理者アクセスが必要です。このソリューションのデプロイは、通常、新しい AWS アカウントをセットアップするときに組織の管理者が行います。次の 2 つの種類のアカウントにアクセスする必要があります。
- サンドボックスアカウントこのアカウントで、アプリケーションチームはさまざまな AWS アーキテクチャを試すことができます。前述のように、これは開発アカウントあるいはテストアカウントの場合があります。
- 中央の情報セキュリティアカウント。通常、これはマルチアカウント構造内でセキュリティコンプライアンスをモニタリングおよび実施する情報セキュリティチームが所有しています。

重要: 情報セキュリティアカウントで作成する Lambda 関数には高度なアクセス許可が付与されているため、アカウントを保護するためにもベストプラクティスを厳守してください。アカウントへのアクセスをセキュリティチームメンバーに制限する必要があります。また、サンドボックスアカウント管理者は、この中央の Lambda 機能に、IAM ポリシーの作成以外のサンドボックスアカウントの IAM アクセス許可を与えないでください。

両方の AWS アカウントが AWS マネジメントコンソールを使用するため、両方の AWS アカウントにロールを持ち、コンソールのロールの切り替え機能を使用することを強くお勧めします。エイリアスを各アカウントに添付し、それぞれに異なる色コードを付けると、ログインしているアカウントを常に把握できます。
このソリューション用に作成するすべてのリソースに、同じ AWS リージョンを使用してください。

ステップ 1: ソリューションの前提条件をデプロイする

2 つの AWS アカウントをつなぐパイプラインを構築する前に、最初に両方のアカウントで必要なリソース (IAM ロールや暗号化キーなど) を設定する必要があります。通常、組織が初めてにサンドボックス、開発、テスト環境をセットアップする際に、この設定はセキュリティチームのガイドラインに従って行われます。

重要

このセクションで作成する最初のセットアップに加えて、セキュリティチームは、サンドボックス、開発、またはテストアカウントの管理者が AdministratorAccess IAM ポリシーのようなそのアカウントタイプのために許可されたセキュリティポリシーを満たさない IAM ポリシーを添付することを明示的に拒否する必要があります。加えて、セキュリティチームは、アカウントの現在や将来のユーザー、グループ、あるいはロールに、(たとえば) CreatePolicy、CreatePolicyVersion、PutRolePolicy、PutUserPolicy、PutGroupPolicy、UpdateAssumeRolePolicy といった IAM ポリシーを直接設定や更新するアクセス許可がないことを確認する必要があります。アクセス許可の作成は、自動化パイプラインを介してのみ実行できるようにする必要があります。これについては、後ほど、作成する方法を説明します。

これから説明するソリューションは最低限の特権の作成に焦点を当てているため、セキュリティチームがソリューションを IAM アクセス許可の境界と組み合わせて、このソリューションで定義されているすべてのアクセス許可が組織内のあらゆる種類のアカウントの一連の定義済みアクセス許可がスコープを指定するようにしておくことを強くお勧めします。たとえばアカウント管理者は、これらのプリンシパルに添付されるアクセス許可を制限する、定義済みアクセス許可の境界のセットを持つ IAM ユーザーまたはロールの作成のみが許可されることがあります。アクセス許可の境界の詳細については、こちらの AWS セキュリティブログの投稿をご参照ください。

サンドボックスアカウントの前提条件を作成する

以下の手順に従って、AWS CloudFormation テンプレートをデプロイして、サンドボックスアカウントに次のリソースを作成します。

サンドボックス管理者が IAM ポリシーをアップロードする S3 バケット
自動化パイプラインが IAM ポリシーを格納する S3 バケットにアクセスするための IAM ロール
S3 バケットの IAM ポリシーを暗号化するための AWS KMS キー

デフォルトのブラウザでサンドボックスアカウントにログインしている間に、こちらのリンクをクリックして、サンドボックス環境の前提条件で AWS スタックを起動します。テンプレート URL が既に入力された状態で、CloudFormation コンソールにリダイレクトされます。

図 2: 入力済みの URL を備えた CloudFormation コンソール
[Next] をクリックし、オプションでスタックの名前を指定します。推奨されるスタック名、Sandbox-Pipeline は既に入力されています。
テンプレートは、セキュリティアカウントの AWS アカウント ID を入力できる CentralAccount という入力パラメータを定義しています。セキュリティアカウントのアカウント 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 の Output タブ

情報セキュリティアカウントの前提条件を作成する

以下の手順に従って、情報セキュリティアカウントに、次のリソースを作成する CloudFormation テンプレートをデプロイします。

中央の Lambda 関数を呼び出して、サンドボックスアカウント KMS キーへのアクセスを提供するために、自動化パイプラインが使用する IAM ロール
サンドボックスアカウントでロールを引き受けて、IAM ポリシーを管理するために、中央の Lambda 関数が使用する IAM ロール

デフォルトのブラウザでサンドボックスアカウントにログインしている間に、こちらのリンクをクリックして、サンドボックス環境の前提条件で AWS スタックを起動します。テンプレート URL が既に入力された状態で、CloudFormation コンソールにリダイレクトされます。
[Next] をクリックし、オプションでスタックの名前を指定します。推奨されるスタック名、Sandbox-Pipeline は既に入力されています。
次の入力パラメーターフィールドに入力します。
- SandboxAccount: サンドボックスアカウントの AWS アカウントID。
- ArtifactBucket: サンドボックスアカウントで実行した以前のスタックのテキストエディタでメモしたバケット名
- CMKARN: サンドボックスアカウントで実行した以前のスタックのテキストエディタでメモした KMS キーの Amazon リソース名 (ARN)
- 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] をクリックします。次のフィールドに値を指定します。

名前。これは、情報セキュリティアカウントの前提条件を設定するときに、ステップ 1 で CloudFormation の入力パラメータ PolicyCheckerFunctionName として定義した関数名と同じである必要があります。ステップ 1 でデフォルト値を変更しなかった場合、デフォルトは PolicyChecker のままです。
ランタイム。Python 2.7。
ロール。ロールを設定するには、[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)

このサンプルコードは、すべてのアカウントリソースですべての IAM アクションを許可してしまい、制限が少なすぎるポリシーについて、Alice が送信した IAM JSON ポリシーを Lambda 関数が確認する方法を示しています。サンプルコードには、T2 EC2 インスタンスファミリーの一部ではない Amazon EC2 インスタンスの起動を防ぐ IAM 拒否アクションも示されています。ここで明示的に拒否すると、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 の拒否に注意してください。

パイプラインをさらにテストする場合は、ポリシーを変更すれば、すべてのリソースですべてのアクションを許可できます。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 でフォローしてください。

Amazon Web Services ブログ