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

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

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

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

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

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

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

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

アジェンダ
⚫ IAMとは？
⚫ まとめ
8

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

IAM の構成要素
⚫ User
⚫ Group
⚫ Policy
⚫ Role
10

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 Only
https://www.amazon.com/SafeNet-IDProve-Time-based-6-Digit-Services/dp/B002CRN5X8
Authy
https://chrome.google.com/webstore/detail/authy/gaedmjdfmmahhbjefcbgaolhhanlaolb?hl=en
YubiKey 4
https://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",
"Resource": ["*"]
},
{
"Effect": "Deny",
"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",
"Resource": ["*"]
},
{
"Effect": "Deny",
"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",
"Resource": ["*"]
},
{
"Effect": "Deny",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
}
},
"Resource": ["*"]
}
]
}
⚫ Resource
⚫ ステートメントで取り扱う一
連のオブジェクト
⚫ ARN (Amazon Resource
Name) で指定
⚫ ワイルドカード使用可能
⚫ 例
⚫ S3バケット
18

IAM Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": ["*"]
},
{
"Effect": "Deny",
"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",
"Resource": ["*"]
},
{
"Effect": "Deny",
"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_policie
s_evaluation-logic.html
20

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>
AssumeRole
IAM User IAM Role
23

Temporary Credential
IAM 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

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とは？
⚫ まとめ
26

で、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 アカウントのルートユーザーのアクセスキーをロックする
3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する
4. AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる
9. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
以下の3つに分類
•識別／ID管理
•認証
•認可／権限管理
29

IAM ベストプラクティス（識別／ID管理）
31

32

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

34

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

IAM ベストプラクティス（認証）
1. AWS アカウントのルートユーザーのアクセスキーをロック
する
4. Amazon EC2 インスタンスでロールを使用する
39

する
40

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

する
42

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

パスワードポリシー 44

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

する
46

特権ユーザーに対して 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
ポリシー変数

する
49

Amazon EC2 インスタンスでロールを使用する
• IAM RoleをEC2インスタンスに割り当てた場合、
インスタンスメタデータから一時認証情報を取得可能
• AWS CLIやAWS SDKを利用したアプリケーションでは
動的に認証情報を取得可能
50
import boto3
ec2 = boto3.client('ec2')
# Retrieves all regions/endpoints that work with EC2
response = ec2.describe_regions()
print('Regions:', response['Regions'])
# Retrieves availability zones only for region of the ec2 object
response = 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/InstanceCredential
Exfiltration
• EC2インスタンスに割り当てられたIAM Roleから取得さ
れた一時認証情報が外部のIPアドレスから利用された場
合に通知（検知のみ）
52

する
53

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

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

【補足】スイッチロール
New – Cross-Account Access in the AWS Management Console
https://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-federation
57

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

する
59

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

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

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

する
63

認証情報を定期的にローテーションする
• 永続的な認証情報を定期的に変更
• パスワード
• アクセスキー
• 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 定義のポリシーを使用して可能な限りアクセス権限を
割り当てる
70

割り当てる
71

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-groups
72

割り当てる
73

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

割り当てる
76

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

アクセスアドバイザー 79

割り当てる
80

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

割り当てる
83

追加セキュリティに対するポリシー条件を使用する
• 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.html
85

【補足】 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.html
87

【補足】タグを条件に利用したポリシー
{
"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.html
88

【利用例】特権を一時的に付与する承認ワークフロー
• 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

アジェンダ
⚫ IAMとは？
⚫ まとめ
91

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

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

More Related Content

What's hot (20)

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

More from Nobuhiro Nakayama (20)

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