Movatterモバイル変換

ビジネスを阻害しないAWS アカウントの管理2018/10/5 Nobuhiro Nakayama

スライドは後で入手することが出来ますので発表中の内容をメモする必要はありません。写真撮影をする場合はフラッシュ・シャッター音が出ないようにご配慮ください

3今日のお題Identity and Access Management (IAM)

4今日のお題IDと権限の管理

このセッションのゴール⚫ IAMの基礎を理解する⚫ IAMのベストプラクティスを知る⚫ ベストプラクティスに準拠する具体的な方法 / 設定例を知る⚫ 自分（の所属する組織）にとって「現実的な落としどころ」を考える5

自己紹介名前：中山順博所属：AWS事業本部コンサルティング部好きなAWSサービス：IAM, AWS CLI, Systems Manager6

アジェンダ⚫ IAMとは？⚫ IAMのベストプラクティス⚫ まとめ7

IAM とは？⚫ AWSのリソースに安全にアクセスしてもらうための仕組み⚫ 利用者を識別（ID管理）⚫ 利用者の認証⚫ 利用者への権限付与（認可）9

IAM の構成要素⚫ User⚫ Group⚫ Policy⚫ Role10

IAM User⚫ AWSを操作するためのユーザー⚫ 認証情報を設定⚫ コンソールにアクセスするためのログインパスワード⚫ プログラムからアクセスするためのアクセスキー⚫ 2つまで設定可能⚫ 認証要素として所有物認証を追加可能（多要素認証）⚫ IAM Group のメンバーになることで権限を付与⚫ ユーザーに対して直接権限を付与することも可能11

IAM Group⚫ IAM Userをまとめる機能⚫ IAM Groupに対して権限を付与可能⚫ IAM Userをメンバーにすることでまとめて権限を付与12

アクセスキー⚫ アクセスキーとシークレットアクセスキーで構成$ aws iam create-access-key --user-name xxxxxxxx{"AccessKey": {"UserName": “xxxxxxxx","Status": "Active","CreateDate": "2018-10-03T15:49:30Z","SecretAccessKey": “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","AccessKeyId": “XXXXXXXXXXXXXXXXXXXX"}}13

多要素認証SafeNet IDProve 100 6-digit OTP Token for Use with Amazon Web Services Onlyhttps://www.amazon.com/SafeNet-IDProve-Time-based-6-Digit-Services/dp/B002CRN5X8Authyhttps://chrome.google.com/webstore/detail/authy/gaedmjdfmmahhbjefcbgaolhhanlaolb?hl=enYubiKey 4https://www.amazon.co.jp/Yubico-YUBIKEY4-%E6%AD%A3%E8%A6%8F%E8%B2%A9%E5%A3%B2%E4%BB%A3%E7%90%86%E5%BA%97%E5%93%81-YubiKey-4/dp/B018Y1Q71M/物理TOTPトークン仮想TOTPトークン（アプリ）U2F準拠セキュリティキー【注意】※ 2019 年 2 月 1 日に SMS MFA のサポート停止14

IAM Policy⚫ AWSに対するアクセス権限を定義したもの⚫ JSONで記述⚫ Default Deny⚫ 権限を明示的に付与しない限り、何の権限も付与されない15{"Version": "2012-10-17","Statement": [{"Effect": “Allow","Action": ["ec2:TerminateInstances"],"Condition": {"IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}},"Resource": ["*"]}]}

IAM Policy{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["ec2:TerminateInstances"],"Resource": ["*"]},{"Effect": "Deny","Action": ["ec2:TerminateInstances"],"Condition": {"NotIpAddress": {"aws:SourceIp": ["192.0.2.0/24","203.0.113.0/24"]}},"Resource": ["*"]}]}⚫ Effect⚫ ステートメントの結果を許可または明示的な拒否のどちらにするかを指定16

IAM Policy{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["ec2:TerminateInstances"],"Resource": ["*"]},{"Effect": "Deny","Action": ["ec2:TerminateInstances"],"Condition": {"NotIpAddress": {"aws:SourceIp": ["192.0.2.0/24","203.0.113.0/24"]}},"Resource": ["*"]}]}⚫ Action⚫ 許可または拒否される特定のアクションを指定⚫ ワイルドカード使用可能17

IAM Policy{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["ec2:TerminateInstances"],"Resource": ["*"]},{"Effect": "Deny","Action": ["ec2:TerminateInstances"],"Condition": {"NotIpAddress": {"aws:SourceIp": ["192.0.2.0/24","203.0.113.0/24"]}},"Resource": ["*"]}]}⚫ Resource⚫ ステートメントで取り扱う一連のオブジェクト⚫ ARN (Amazon ResourceName) で指定⚫ ワイルドカード使用可能⚫ 例⚫ S3バケット18

IAM Policy{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["ec2:TerminateInstances"],"Resource": ["*"]},{"Effect": "Deny","Action": ["ec2:TerminateInstances"],"Condition": {"NotIpAddress": {"aws:SourceIp": ["192.0.2.0/24","203.0.113.0/24"]}},"Resource": ["*"]}]}⚫ Condition⚫ ポリシーを実行するタイミングの条件を指定⚫ 例⚫ リクエスト元IPアドレス⚫ MFAデバイスでの認証⚫ タグ⚫ 時刻19

IAM Policy{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["ec2:TerminateInstances"],"Resource": ["*"]},{"Effect": "Deny","Action": ["ec2:TerminateInstances"],"Condition": {"NotIpAddress": {"aws:SourceIp": ["192.0.2.0/24","203.0.113.0/24"]}},"Resource": ["*"]}]}⚫ 任意のEC2インスタンス削除を許可（前半のStatement）⚫ 指定されたIPアドレス以外からのEC2インスタンス削除を拒否（後半のStatement）⚫ DenyはAllowより優先 ※1後半のStatementで指定されたIPアドレスからのEC2インスタンス削除を許可※1 ポリシーの評価論理https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html20

IAM Policy の種類⚫ 管理ポリシー⚫ 独立したリソースとして定義できるポリシー⚫ 再利用可能⚫ 5世代前までのポリシーを保持でき、ロールバック可能⚫ AWSによる定義済のポリシーが提供されている⚫ インラインポリシー⚫ User, Group, Roleに対して直接設定できるポリシー⚫ （インラインポリシーを利用する機会は少ない）21

IAM Role⚫ AWSのサービス（EC2など）や他のAWSアカウントやIdentity Provider (IdP) に権限を委任する仕組み⚫ STS(Security Token Service)から一時的な認証情報を生成⚫ アクセスキーなど、永続的な認証情報を利用するよりセキュアなシステム運用が可能⚫ Roleに設定されたPolicyの権限を取得できる⚫ Roleに設定された信頼先からであれば一時認証情報を取得可⚫ Roleでは認証をしていない⚫ 信頼先で認証されていることが前提22

一時的な認証情報を生成（1／3）$ aws sts assume-role ¥--role-arn arn:aws:iam::XXXXXXXXXXXX:role/<ROLE NAME> ¥--role-session-name <SESSION NAME>AssumeRoleIAM User IAM Role23

一時的な認証情報を生成（2／3）Temporary CredentialIAM User IAM Role{"AssumedRoleUser": {"AssumedRoleId": "AXXXXXXXXXXXXXXXXXXXX:<SESSION NAME>","Arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/<ROLE NAME>/<SESSION NAME>"},"Credentials": {"SecretAccessKey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","SessionToken":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","Expiration": "2018-10-04T02:48:54Z","AccessKeyId": "XXXXXXXXXXXXXXXXXXXX"}}有効期限24

一時的な認証情報を生成（3／3）API Request(with Temporary Credential)IAM User AWS Service$ export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX$ export AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX$ export AWS_SESSION_TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX$ export AWS_DEFAULT_REGION=us-west-2$ aws ec2 describe-instances※ AWS SDK / CLI を利用する場合、明示的指定しなくても自動で認証情報を取得可能（説明のため、この資料ではあえて環境変数を利用）25

で、IAMの設計ってどうしたらいいの？⚫ 組織がゼロからセキュリティポリシーを確立することは困難⚫ ベストプラクティス / フレームワークに則ることで効率的にセキュアな運用設計を実現⚫ ただし、原理主義は禁物⚫ 原理主義に陥ると、開発スピード低下のリスクが27本日はAWSが提供するIAM ベストプラクティスを紹介https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html

IAM ベストプラクティス1. AWS アカウントのルートユーザーのアクセスキーをロックする2. 個々の IAM ユーザーの作成3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する4. AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる5. 最小権限を付与する6. アクセスレベルを使用して、IAM 権限を確認する7. ユーザーの強力なパスワードポリシーを設定8. 特権ユーザーに対して MFA を有効化する9. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する10. ロールを使用したアクセス許可の委任11. アクセスキーを共有しない12. 認証情報を定期的にローテーションする13. 不要な認証情報を削除する14. 追加セキュリティに対するポリシー条件を使用する15. AWS アカウントのアクティビティの監視28

IAM ベストプラクティス1. AWS アカウントのルートユーザーのアクセスキーをロックする2. 個々の IAM ユーザーの作成3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する4. AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる5. 最小権限を付与する6. アクセスレベルを使用して、IAM 権限を確認する7. ユーザーの強力なパスワードポリシーを設定8. 特権ユーザーに対して MFA を有効化する9. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する10. ロールを使用したアクセス許可の委任11. アクセスキーを共有しない12. 認証情報を定期的にローテーションする13. 不要な認証情報を削除する14. 追加セキュリティに対するポリシー条件を使用する15. AWS アカウントのアクティビティの監視以下の3つに分類•識別／ID管理•認証•認可／権限管理29

IAM ベストプラクティス（識別／ID管理）1. 個々の IAM ユーザーの作成2. AWS アカウントのアクティビティの監視31

個々の IAM ユーザーの作成• ユーザーは必ず利用者個別に発行しましょう• 共有した場合、操作ログから「誰が」がわからない• 認証情報が漏洩した場合、認証情報を無効化しやすい• User や Group 別に権限を設定可能33

AWS アカウントのアクティビティの監視• AWSに対する操作を取得可能• CloudTrailでAPI Callを記録• 全てのリージョンで有効化• ログ保存先のS3バケットのアクセスを制御• 改ざんの有無を検証できるオプションを有効化• ConfigでAWSリソース等の変更を記録• IAMのリソースの変更も追跡可能• 必要に応じてログの分析環境を準備• 例 : Athena / QuickSight, CloudWatch Logs / Elasticsearch• 特定の操作をトリガに何らかの処理を実行することも可能• CloudWatch Events + Lambda35

IAM ベストプラクティス（認証）1. AWS アカウントのルートユーザーのアクセスキーをロックする2. ユーザーの強力なパスワードポリシーを設定3. 特権ユーザーに対して MFA を有効化する4. Amazon EC2 インスタンスでロールを使用する5. ロールを使用したアクセス許可の委任6. アクセスキーを共有しない7. 認証情報を定期的にローテーションする8. 不要な認証情報を削除する39

AWS アカウントのルートユーザーのアクセスキーをロック• ルートユーザーとは• アカウント作成時に唯一存在するアカウント• 全ての権限を有する• 権限を制御できない• MFAの設定を強く推奨• ルートユーザーでしかできない作業もある• 普段は利用しないことを推奨• アクセスキーを発行できるが、無効化することを推奨41

ユーザーの強力なパスワードポリシーを設定• 使用できる文字の種別や長さ、再利用の条件などを指定可能• 有効期限を設定した場合、期限切れ後の初回ログインで再設定を要求• ポリシーはアカウントの IAM User 全てに対して有効• そもそも、認証要素がパスワードのみでは強度に限界• 後述する多要素認証の利用を推奨43

パスワードポリシー 44

【補足】NIST800-63における定期パスワード変更の方針• アメリカ国立標準技術研究所（NIST）が発行するElectronicAuthentication Guideline（電子的認証に関するガイドライン）• 2017年6月に改訂• この改訂でパスワードの定期変更は非推奨へ• 変更は漏洩時に実施“Verifierは，記憶シークレットを任意で(例えば，定期的に)変更するよう要求すべきではない(SHOULD NOT)．”OIDF-J・JIPDEC共催OpenID BizDay#11「NIST SP 800-63-3を読む」NIST Special Publication 800-63BDigital Identity Guidelines (翻訳版) Authentication and Lifecycle Managementhttps://www.jipdec.or.jp/sp/topics/event/20171013.html45

特権ユーザーに対して MFA を有効化する• 管理権限を持つIAM Userに追加することを強く推奨• パスワードのみでは認証強度が不十分• MFAの設定を各利用者に実施させることも可能（必要なポリシーは後述）47

IAM ユーザーに MFA デバイスの自己管理を許可 48{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["iam:CreateVirtualMFADevice","iam:EnableMFADevice","iam:ResyncMFADevice","iam:DeleteVirtualMFADevice"],"Resource": ["arn:aws:iam::*:mfa/${aws:username}","arn:aws:iam::*:user/${aws:username}"]},...]}https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_iam_mfa-selfmanage.htmlポリシー変数

Amazon EC2 インスタンスでロールを使用する• IAM RoleをEC2インスタンスに割り当てた場合、インスタンスメタデータから一時認証情報を取得可能• AWS CLIやAWS SDKを利用したアプリケーションでは動的に認証情報を取得可能50import boto3ec2 = boto3.client('ec2')# Retrieves all regions/endpoints that work with EC2response = ec2.describe_regions()print('Regions:', response['Regions'])# Retrieves availability zones only for region of the ec2 objectresponse = ec2.describe_availability_zones()print('Availability Zones:', response['AvailabilityZones'])https://boto3.amazonaws.com/v1/documentation/api/latest/guide/ec2-example-regions-avail-zones.html

インスタンスメタデータから一時認証情報を取得$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>{"Code" : "Success","LastUpdated" : "2018-10-03T18:26:12Z","Type" : "AWS-HMAC","AccessKeyId" : "XXXXXXXXXXXXXXXXXXXX","SecretAccessKey" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","Token" :"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","Expiration" : "2018-10-04T01:00:26Z"}51

【補足】GuardDutyによる一時認証情報の不正利用検知• GuardDuty で以下の Finding Type が提供されている• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration• EC2インスタンスに割り当てられたIAM Roleから取得された一時認証情報が外部のIPアドレスから利用された場合に通知（検知のみ）52

ロールを使用したアクセス許可の委任• EC2インスタンス以外にも権限を委任可能• AWS Service• （CloudFormationの場合）Roleの権限でStackを作成• 他のAWSアカウントやそのアカウントのIAM User• 例 : スイッチロール / Assume Role（他のアカウントへのアクセス）• 外部のIdP• 例 : IDフェデレーション• 応用例• ロールの信頼ポリシーの条件でMFAを要求• 「MFAを設定していないと特権（ロール）を利用できない」などを実現可能54

【補足】スイッチロール 55スイッチロールIAM UserIAM RoleAWS ID : 123456789012 AWS ID : 345678901234

【補足】スイッチロールNew – Cross-Account Access in the AWS Management Consolehttps://aws.amazon.com/jp/blogs/aws/new-cross-account-access-in-the-aws-management-console/56

認証連携の仕組み既存のユーザーのフェデレーションhttps://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_identity-management.html#intro-identity-federation57

AFDSによる認証連携AWS Federated Authentication with Active Directory Federation Services (AD FS)https://aws.amazon.com/jp/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/58

アクセスキーを共有しない• 利用する場合は適切に管理する必要がある• アクセスキーを直接コードに埋め込まない• 異なるアプリケーションには、異なるアクセスキーを使用• アクセスキーを定期的に更新• 使用していないアクセスキーを削除• （必要に応じて）多要素認証を設定• IAM Userから永続的なアクセスキーを発行できるが、可能な限りSTSから一時認証情報を生成して利用すべきAWS アクセスキーを管理するためのベストプラクティスhttps://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-access-keys-best-practices.html60

漏洩事故は後を絶たず・・・ 61

awslabs/git-secrets• コードにアクセスキーがハードコードされてないかチェックするツールが提供されている• commit 時にスキャンしてくれる• commit 済のコードをスキャンすることも可能awslabs/git-secretshttps://github.com/awslabs/git-secrets62$ git secrets --scan

認証情報を定期的にローテーションする• 永続的な認証情報を定期的に変更• パスワード• アクセスキー• IAM Roleを利用していれば、アクセスキーのローテーション自体不要• コンソールや認証情報レポートで認証情報の古さを確認可能64

不要な認証情報を削除する• AWSへのアクセスが不要になった時点で削除• 例• 退職や異動• システム / サブシステムの廃止• プロジェクトの終了• ID / 認証情報の削除が必要になるイベントを事前に定義できているとベター• コンソールや認証情報レポートで認証の状況を確認可能65

IAM 認証情報レポート (Credential Report) 67レポートに含まれる項目（一部省略）• user• arn• user_creation_time• password_enabled• password_last_used• password_last_changed• password_next_rotation• mfa_active• access_key_1_active• access_key_1_last_rotated• access_key_1_last_used_date• access_key_1_last_used_region• access_key_1_last_used_service• access_key_2_active• access_key_2_last_rotated• access_key_2_last_used_date• access_key_2_last_used_region• access_key_2_last_used_service

アクセスキーのローテーション1. 新しいアクセスキーを作成2. 新しいアクセスキーを設定3. 古いアクセスキーを無効化（問題が発生したら再アクティブ化）4. 新しいアクセスキーが使用されていること、古いアクセスキーが使用されなくなったことを確認5. 古いアクセスキーを削除68

IAM ベストプラクティス（認可／権限管理）1. IAM グループを使用する2. AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる3. 最小権限を付与する4. アクセスレベルを使用して、IAM 権限を確認する5. 追加セキュリティに対するポリシー条件を使用する70

IAM グループを使用する• IAM User を IAM Groupのメンバーにすることが可能• IAM Group に権限を付与することで IAM User にまとめて権限を付与• 権限の付与や剥奪が容易ポリシーとグループhttps://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_access-management.html#intro-access-groups72

AWS 定義のポリシーを使用してアクセス権限を割り当て• AWS管理ポリシーを利用可能• 機能別のポリシーと職務機能別のポリシーがある• サービスのアップデートに追従• 開発環境や単一の目的で利用するAWSアカウントには適当• ただし、ResourceやCondition等を利用した細かな制御はカスタマー管理ポリシーを利用する必要がある• AWS管理ポリシーは全てのケースで適当という訳ではない• AWS管理ポリシーとカスタマー管理ポリシーの併用は可能74

最小権限を付与する• 必要最低限の権限を最初に付与 + 必要に応じて権限を追加するアプローチを推奨• Visual Editorを利用してポリシーを作成することが可能• アクセスアドバイザーを利用していないサービスを確認可能• 1つのアカウントを多目的に利用するとポリシーが複雑になりやすい• 目的別に複数のAWSアカウントを利用することでポリシーをシンプルにできる（場合がある）• 拠点とのVPN / 閉域接続が必要な場合にAWSアカウントを分けるとネットワークの複雑性 / コストは増加する77

アクセスアドバイザー 79

アクセスレベルを使用して、IAM 権限を確認する• アクションは以下の5つのレベルに分類• List, Read, Write, Permissions management, or Tagging• ポリシーの概要でポリシーにどのレベルのアクションが許可されているか確認可能• まずは概要を確認し、必要に応じてAction単位で確認• 同じレベルでもサービスによって意味が大きく異なるケースがあるので注意• AWS管理ポリシー”ReadOnlyAccess”では”S3:GetObject”が許可• S3などで機密性の高いデータを保存している場合に注意• EC2などとのReadとは別物81

追加セキュリティに対するポリシー条件を使用する• Conditionを利用することできめ細かな制御が可能• リクエスト送信元IPアドレス• MFA認証の有無• 時刻• リソースに付与されたタグ• ・・・など84

【補足】 IPアドレスを条件に利用したポリシー{"Version": "2012-10-17","Statement": {"Effect": "Deny","Action": "*","Resource": "*","Condition": {"NotIpAddress": {"aws:SourceIp": ["192.0.2.0/24","203.0.113.0/24"]}}}}AWS: 送信元 IP に基づいて AWS へのアクセスを拒否するhttps://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html85

【補足】 MFAを条件に利用したポリシー{"Version": "2012-10-17","Statement": {"Effect": "Allow","Action": ["<SERVICE-NAME-1>:*","<SERVICE-NAME-2>:<ACTION-NAME-A>","<SERVICE-NAME-2>:<ACTION-NAME-B>"],"Resource": "*","Condition": {"Bool": {"aws:MultiFactorAuthPresent": true}}}}86

【補足】時刻を条件に利用したポリシー{"Version": "2012-10-17","Statement": {"Effect": "Allow","Action": "<SERVICE-NAME>:<ACTION-NAME>","Resource": "*","Condition": {"DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},"DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}}}}AWS: 特定の日付内でアクセスを許可するhttps://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws-dates.html87

【補足】タグを条件に利用したポリシー{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["ec2:StartInstances","ec2:StopInstances"],"Resource": "arn:aws:ec2:*:*:instance/*","Condition": {"StringEquals": {"ec2:ResourceTag/Owner": "${aws:username}"}}},{…}]}https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_ec2_tag-owner.html88

【利用例】特権を一時的に付与する承認ワークフロー• Systems ManagerのAutomationを利用• 権限を付与したいIAM User / 権限を委任されたいIAM Role/ 権限が必要な時間帯 / 承認者などを指定• 承認 / ポリシーをIAM Userに設定する2つのステップで構成• 後半のステップで設定するポリシーでConditionを利用https://dev.classmethod.jp/cloud/aws/workflow-to-add-temporary-privilege-by-ssm-automation/89

【おまけ】準拠状況を継続的にチェックしたい⚫ Insightwatchである程度準拠状況をチェック可能⚫ 以下の事項はチェックでしきれない⚫ 個々のIAM Userの利用 / アクセスキーの共有⚫ 発行されたものが共有されているかはわからない⚫ 最小権限の付与 / ポリシー条件の使用⚫ 必要な権限は要件次第なので一概に妥当性を判断できない⚫ ツールでできること / できないことを正しく理解して使いましょう90

まとめ⚫ 利用者 / 目的別にIDを発行しましょう⚫ 監査可能な環境を構築⚫ すでに Identity Provider がある場合には認証連携を検討（IDの二重管理を回避）⚫ 適切な強度の認証を⚫ 最低でも管理者には多要素認証を設定⚫ 可能な限り一時的な認証情報を利用⚫ 権限を可能な範囲で最小化⚫ AWSが提供するポリシーを最大限活用⚫ 必要に応じてマルチアカウントで権限分離⚫ 原理主義に陥らず、受容可能なリスクの見極めよう92

Movatterモバイル変換

Developers.IO 2018 ビジネスを阻害しない！AWS アカウントの管理

Recommended

More Related Content

What's hot(20)

Similar to Developers.IO 2018 ビジネスを阻害しない！AWS アカウントの管理(20)

More from Nobuhiro Nakayama(20)

Recently uploaded(8)

Developers.IO 2018 ビジネスを阻害しない！AWS アカウントの管理