Más contenido relacionado La actualidad más candente (20) Similar a AWS Black Belt Techシリーズ AWS IAM (20) Más de Amazon Web Services Japan (20) AWS Black Belt Techシリーズ AWS IAM1. AWS Identity and Access Management
(AWS IAM)
AWS Black Belt Tech Webinar 2015 (旧マイスターシリーズ)
アマゾンデータサービスジャパン株式会社
シニアセキュリティコンサルタント 高田 智己
2015.06.17
1
3. AWS Black Belt Tech Webinar 2015
• 今後の配信予定
– 6/24(水)Amazon EC2 Container Service
お申し込み:http://bit.ly/1Gq0gQQ
7月は「AWS 運用機能月間」です!
– 7/1(水)AWS Cloud Watch/Cloud Watch Logs
– 7/8(水)AWS support & Trusted Advisor
• イベントスケジュール
http://aws.amazon.com/jp/event_schedule/
3
6. AWS Identity and Access Management (IAM)
• AWS操作をよりセキュアに行うための認証・認可の仕組み
• AWS利用者の認証と、アクセスポリシーを管理
AWS操作のためのグループ・ユーザー・ロールの作成が可能
グループ、ユーザーごとに、実行出来る操作を規定できる
ユーザーごとに認証情報の設定が可能
開発チーム 運用チーム
6
8. IAM ユーザー
• AWS操作用のユーザー
– 1AWSアカウントで5000ユーザーまで作成可能
• ユーザーごとに設定可能な情報
– ユーザー名
• IAMユーザーの識別と、マネジメントコンソールへのログインに使用
• 64文字までのアルファベット、数字、+=,.@-_
– パス(オプション)
• ユーザーにオプションとしてセットできる情報
• パスを元にユーザーの検索が可能
• 組織階層やプロジェクトなどをセット 例)/aws/sa/
• 512文字までのBasic Latin文字(アルファベット、数字、!"#$%&'()=~|-^@`{[}]*:+;?_)
• 開始と終了が/であること
– 所属グループ
• 10のグループまで設定可能
– パーミッション
• AWSサービスへのアクセス権限
• JSON形式でポリシーを記述
8
9. IAM グループ
• IAMユーザーをまとめるグループ
– 1AWSアカウントで100グループまで作成可能
• グループに設定可能な情報
– グループ名
• グループの識別に使用
– パス(オプション)
• 組織階層などをセット 例)/aws/
– パーミッション
• グループに設定したパーミッションは、IAMユーザーに付与したパーミッションと同時に評価
• 評価方法は後述
Group
9
11. IAMで使用する認証情報(2)
• AWSマネジメントコンソールへのログインパスワード
– デフォルトは未設定(ログインできない)
– 128文字までのBasic Latin文字
– パスワード変更時のポリシー設定が可能
• AWSアカウントごとに設定
• 最低パスワード長、大文字小文字等
• MFA(多要素認証)
– ハードウェアMFAと仮想MFAのいずれかを利用可能
– ハードウェアMFA
• Gemalto社からAWS用のデバイスを購入
– Tokenタイプ
– カードタイプ
• http://onlinenoram.gemalto.com/
– 仮想MFA
• スマートフォンやPCにインストール
• Google Authenticatorなど、TOTP実装のソフトが利用可能
11
15. 認証情報の定期的なローテーション
IAMユーザーのパスワードやAccess
Key/Secret Access Keyは定期的にローテー
ションすることを推奨
認証情報の利用状況はIAMのCredential Report
機能で確認可能
ユーザーの作成日時
最後にパスワードが使われた日時
最後にパスワードが変更された日時
MFAを利用しているか
Access KeyがActiveか
Access Keyのローテートした日時
Access Keyを最後に使用した日時
Access Keyを最後に利用したAWSサービス
証明書はActiveか
証明書のローテートした日時
15
20. IAMポリシー
• AWSアクセスに対する権限設定
• JSON形式のアクセスポリシー言語でアクセス条件を記述
– http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/policy-reference.html
{
"Statement
{
"Effect": "Allow",
"Action": [
" s3:ListBuckets ",
" s3:Get * "
],
"Resource": [
" arn:aws:s3:::mybucket "
],
"Condition": {
"IpAddress": {
"aws:SourceIP": [“176.32.92.49/32“]
}
}
}
]
}
このブロックを1条件として、
アクセス権限をチェック
20
27. アクセス条件の記述
{
"Effect": "Allow",
"Action": [
" s3:ListBuckets ",
" s3:Get * "
],
"Resource": [
"arn:aws:s3:::mybucket"
],
"Condition": {
"IpAddress": {
"aws:SourceIP":
[“176.32.92.49/32“]
}
}
}
Effect:
許可の設定なら”Allow”
拒否の設定なら”Deny”
Action:
対象となるAWS操作を指定
Resource:
対象となるAWSリソースを指定
Condition:
このアクセス制御が有効になる
条件の設定
この例の場合、
「アクセス元IPが176.32.92.49だったら、S3のListBucketsとGet系の操作を許
可する」という意味
27
28. Action
• 「Action」は、操作自体に対する設定
ec2:runInstances
ec2:AttachVolume
s3:CreateBucket
s3:DeleteObject
ワイルドカード指定可能
例)ec2:Describe*
指定の操作以外の場合は「NotAction」を使用
例)“NotAction”: “iam:*” (IAMの操作以外を許可する)
"Action": [
" s3:ListBuckets",
" s3:Get*"
]
28
29. Resource
• 「Resource」は操作対象を指定する設定
EC2インスタンス
EBSボリューム
S3バケット
S3オブジェクト
• ARN(Amazon Resource Name)で記述
“arn:aws:”で始まる文字列
arn:aws:service:region:account:resource
例) arn:aws:s3:::mybucket
• 指定リソース以外の場合は「NotResource」を使用
– 例) “NotResource” : “arn:aws:s3:::hoge”
"Resource": [
" arn:aws:s3:::mybucket"
]
http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-arns-and-namespaces.html29
31. Conditionの演算子
• 文字列
– 完全一致、部分一致など
• 数値
– 一致、以上、以下など
• 日付および時間
– 一致、日付の後先など
• ブール
• IP アドレス
– 指定のアドレス、指定範囲など
• Amazon リソース名
– 完全一致、部分一致など
• ...IfExists
– 上記演算子に付与。変数がない場合無視
• 条件キーの有無
"Condition": {
"StringEquals":
{"ec2:ResourceTag/stack":
“prod"}
}
"Condition": {
“streq":
{"ec2:ResourceTag/stack":
“prod"}
}
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptio
ns.html#Condition
31
32. ポリシー変数
• 全てのリクエストで利用できるキー
– aws:CurrentTime
– aws:EpochTime
– aws:TokenIssueTime
– aws:principaltype
– aws:SecureTransport
– aws:SourceIp
– aws:UserAgent
– aws:userid
– aws:username
• AWSサービス固有のキー
– s3:prefix
– sns:Protocol
– ec2:ResourceTag/tag名 など
"Condition": {
"IpAddress":
{"aws:SourceIP":
“176.32.92.49/32“}
}
例えば、API呼び出し/コンソール利用を指定
のIPアドレスだけに絞りたい場合に利用。
注)コンソールに関してはログインはできて
も操作する権限がないという状態になります。
32
33. IAMをサポートするサービス
IAMのサポート 対応状況
アクションレベルの
権限
ほとんど全てのAWSサービスでサポート
(AWS Supportを除く)
リソースレベルの
権限
多くのAWSサービスに対応。下記はサポートしていない
ECS, Auto Scaling, CloudFront, Import/Export, ElastiCache,
Direct Connect, Directory Service, CloudTrail, Config,
CloudWatch, CloudHSM, EMR, AppStream, SES, Cognito,
Mobile Analytics, WorkDocs
タグベースの
アクセス権限
下記のみサポート
EC2, RDS, VPC, Data Pipeline, SWF
一時的なセキュリティ
認証のサポート
ほとんど全てのAWSサービスでサポート
(Cloud HSMを除く)
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/Using_SpecificProducts.html
2015年6月現在
33
38. IAM Policy Simulator
• IAMのウィザード内、IAMユーザー/グループ/ロールのPermissionsタブ、
もしくは単体のサイトで利用可能
https://policysim.aws.amazon.com/home/index.jsp
• プロダクションへの実装前にポリシーをテスト可能
– パーミッションのトラブルシューティング
– Conditionの条件を入れたテスト
– ポリシー変数を入れたテスト
New!2015年5月
38
39. IAM Policy Validator
• 自動的に既存の IAMポリシーを調べ、IAMポリシーの文法に準拠しているか確認
• ポリシーに対する推奨の変更を提示
• Policy Validator を使用できるのは、準拠していないポリシーがある場合のみ
1) IAMコンソールにポリシーの文法を直す旨の表示。
2) IAMポリシーの文法に準拠していないポリシーのリスト。
3) ポリシーに対する推奨の変更が表示され、それを適用することも
可能
39
41. リソースベースのポリシーによるクロスアカウントアクセス
• AWSアカウントを超したアクセス許可
– S3,SQS,SNSなどで利用可能
{
"Statement" : {
"Effect":"Allow",
"Principal" : {
“AWS”:“arn:aws:iam::Account Bの番号:root"
},
"Action":"s3:*",
"Resource":"arn:aws:s3:::mybucket/*"
}
}
1.Account Aのバケットに以下のポリシーを設定
2.Account Bに、mybucketへアクセス権限付与
Principalは、実行を
しているユーザーに
対する条件設定
41 http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/roles-resourcebasedpolicies-
compare.html
42. 記録される情報には以下のようなものが含まれる
• APIを呼び出した身元(Who)
• APIを呼び出した時間(When)
• API呼び出し元のSource IP(Where)
• 呼び出されたAPI(What)
• APIの対象となるAWSリソース(What)
• 管理コンソールへのログインの成功・失敗
(rootアカウントの失敗は2015年6月現在未サポート)
AWS CloudTrailはAWSアカウントで利用されたAPI Callを記録し、S3上にログを保存するサービス。
AWSのリソースにどのような操作が加えられたか記録に残す機能であり全リージョンでの有効化を推奨。
適切なユーザーが与えられた権限で環境を操作しているかの確認と記録に使用。
ユーザーのアクティビティの記録
42
47. AWSCredentials credentials =
new BasicAWSCredentials(“アクセスキー”,”シークレットキーID”);
AmazonEC2 ec2 = new AmazonEC2Client(credentials);”
ec2.describeInstances();
• AWS SDKを利用する場合、認証情報取得と有効期限切れ前の再取得
を自動的に実施可能
AWS CLIはIAM Roleに対応済み
• http://aws.amazon.com/jp/cli/
AmazonEC2 ec2 = new AmazonEC2Client();”
ec2.describeInstances();
IAM Role利用後
IAM Role適用のインスタンス
上では、認証情報の設定が不要
47
49. AWS Security Token Service(STS)とは
• 一時的に利用するトークンを発行するサービス
• 動的にIAMユーザーを作成し、ポリシーを適用できる
– STSはユーザー数制限なし
• IAM Role for EC2は、このSTSを利用
– Assume Role
49
50. Temporary Security Credentialsとは
• AWSに対する、一時的な認証情報を作成する仕組み
– 期限付きの認証情報(認証チケット)
• ユーザーに対して、以下の3つのキーを発行
アクセスキー(ASIAJTNDEWXXXXXXX)
シークレットアクセスキー(HQUdrMFbMpOHJ3d+Y49SOXXXXXXX)
セッショントークン
(AQoDYXdzEHQakAOAEHxwpf/ozF73gmp9vZDWDPkgFnzwSG/3ztBw9Z4IUslNNn503+3Se
N0nwI3wcdLR8y8Ulv9cnksMrBGjRVrJl2xg+/CRnI9nJ1tteHp6yso3sP0BVvnxLpNwyIUpHrcT
Ht+8v2P6Y9/VX2zl8Hc/cy6La0r1/GuiHb9NEwqt6VIgjPWCZzHXzX8XsUObKhMnAUkY2IdTM
rNKXcqVk8VbC6BNTqWsMIIfQPz9fDjKK1ifAFmHVSWvUxio94n+ebXXpy1NuHnt5JEGV34VPL
MsrpZ86b+eulKNE1suoQ8TM5E1O66rYwizkq6w+cJovUnMxg6ESASBvolsrEioLiP+SE7cX1i8g
RrSG9/KT59GYTlhTzStjjFroCAqZu4KYplGUMCDl1g0twrdXeymsu3GG70Qwu0wSi3WjkW8VPi
ajahJXCEgp6gIgXElwkrBO01H5Y9NNDEyQaq8ocOGBPVRu+DS9LMs9SHASXimnnVeIN+1FV
kXXXXXXXXXXXXXXXXXXXXXXXX)
50
52. 認証情報を取得する方法
• Self-sessions (GetSessionToken)
• Federated sessions (GetFederationToken)
• Assumed-role sessions
• AssumeRole
• AssumeRoleWithWebIdentity
• AssumeRoleWithSAML
Session
Access Key Id
Secret Access Key
Expiration
Session Token
Temporary
Security
Credentials
52
53. 認証情報取得のためのAPI
STSで利用できるAPI Action 概要
GetSessionToken 自身で利用するIAMユーザーのtemporary security
credentialsを取得するためのアクション
GetFederationToken 認証を受けたFederatedユーザーのtemporary security
credentialsを取得するためのアクション
AssumeRole 既存のIAMユーザーの認証情報を用いて、IAM Roleの
temporary security credentialsを取得するためのアクショ
ン。
AssumeRoleWithWebIdentity AmazonやFacebook、Googleによる承認情報を使用して
ロールを引き受け、temporary security credentialsを取得
するためのアクション
AssumeRoleWithSAML idPによる認証とSAMLのアサーションをAWSにポストする
ことでロールを引き受けtemporary security credentialsを
取得するためのアクション
http://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html53
54. 認証情報の有効期限
• トークンのタイプにより有効期限は様々[Min/Max/Default]
• Self (Account) [15 min / 60 min / 60 min]
• Self (IAM User) [15 min / 36 hrs / 12 hrs]
• Federated [15 min / 36 hrs / 12 hrs]
• Assumed-role [15 min / 60 min / 60 min]
• 発行したチケットは延長や期間短縮は出来ない
• 即座にアクセス制御したい場合は、発行に使用したIAMユーザーやIAMロールの権限を変更する
Session
Access Key Id
Secret Access Key
Expiration
Session Token
54
55. AWS STS in all AWS regions New!2015年2月
• STSのエンドポイントが全リージョンに拡張
• デフォルトではSTSはグローバルサービスとして利用
単一エンドポイント:https://sts.amazonaws.com
• IAMのAccount Settingsより各リージョンでSTS機能を
アクティベート可能
– レイテンシーの低減
– 冗長性の構築
• 有効化したリージョンでのCloudTrailの使用を忘れない
http://docs.aws.amazon.com/ja_jp/STS/latest/UsingSTS/sts-enableregions.html55
57. 本番アカウント
Acct ID: 111122223333
s3-role
{ "Statement": [
{
"Effect": "Allow",
"Action": “s3:*",
"Resource": "*"
}
]
}
開発アカウント
Acct ID: 123456789012
開発者Aのアクセスキーによ
る認証
S3-roleを引き受け、一時的なア
クセスキーを取得
一時的なアクセスキーによる
S3APIの呼び出し
{ "Statement": [{
"Effect": "Allow",
"Action": “sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/s3-role"
}
]
}
{ "Statement": [{
"Effect":"Allow",
"Principal":{"AWS":"arn:aws:iam::123456789012:root"},
"Action":"sts:AssumeRole"
}
]
}
IAMロールによるクロスアカウントアクセスの動作
S3-roleを誰が引き受けられるか定義したポリシーをs3-roleに設定本番アカウントのs3-roleの引き受けを許可するポリシーを開発者Aに設定
開発者A(IAM User)
s3-roleに付与されているポリシー
STS
57
61. ユースケース: API FederationによるS3アクセス
(Sample - http://aws.amazon.com/code/1288653099190193)
• AWS API (S3*)へのアクセスを付与
• Identity provider
– Windows Active Directory
– ADグループメンバーシップに応じた権限付与
• GetFederationToken APIの利用
61
62. 5
• Access Key
• Secret Key
• Session Token
Get Federation Token
Response
AWS API Federationの動作
Customer (Identity Provider) AWS Cloud (Relying Party)
AWS Resources
User
Application
Active
Directory
Federation
Proxy
4
Get Federation
Token Request
3
2
S3 Bucket
with Objects
Amazon
DynamoD
B
Amazon
EC2
認証情報の
リクエスト
1
認証情報の
受け取り
6
APP
Federation
Proxy
• GetFederationTokenRequest()の利用には
Proxy上のIAMユーザーのクレデンシャルを
利用
• そのIAMユーザーの権限はフェデレーション
ユーザーの権限をカバーしている必要がある
• Proxyはこの特権的なクレデンシャルをセ
キュアに保管する必要がある
AWS APIの
呼び出し
7
http://aws.typepad.com/aws_japan/2011/08/aws-identity-and-access-management-now-with-
identity-federation.html
62
63. ユースケース: Console Federation
(Sample - http://aws.amazon.com/code/4001165270590826)
• 既存のIdPによる管理コンソールへのシングルサインオン
• Identity provider
– Windows Active Directory
– ADグループメンバーシップに応じた権限付与
– ADグループに応じたIAMロールの選択
• AssumeRole APIの利用
63
64. Console Federationの動作
Customer (IdP) AWS Cloud (Relying Party)
AWS
Management
Console
Browser
interface
Corporate
directory
Federation
proxy
1 URLにアクセス
3
2
コンソールへのリ
ダイレクト
10
ログインURLの作成9
4 List RolesRequest
8
Assume Role Response
Temp Credentials
• Access Key
• Secret Key
• Session Token
7 AssumeRole Request
ロールを選択でき
るcombo
Boxの作成
6
Federation
proxy
• AssumeRoleRequest()を利用するため
Proxy上のIAMユーザーのクレデンシャ
ルを利用
• IAMユーザーの権限はListRolesと
assume roleを行えるものが必要
• Proxyはこのクレデンシャルをセキュア
に保管する必要がある
5
List RolesResponse
64
65. SAML 2.0によるSSO Federation
• Security Assertion Markup Language (SAML)のサポート
• AWSリソースへのアクセスにSAMLを利用した既存のID管理ソフトウェアを利用
(ADFS, Shibboleth etc)
• AWS管理コンソールへのSSOにも利用可能
• 新しいassumeRoleWithSAML APIによりAPIフェデレーション実施
65
66. SAMLによるConsole Federationの動作
Enterprise (Identity Provider) AWS (Service Provider)
AWS Sign-in
Browser
interface
Corporate
identity
store
Identity
provider
1内部ポータルへのアクセス
ポータルはIdPとしても機能
2 認証応答
の受け取り
5
AWS管理コンソールへ
のリダイレクト
3
新しいAWSのサインイン・
エンドポイントに対して
SAMLアサーションをポスト
4
http://aws.typepad.com/aws_japan/2013/11/aws-identity-and-access-management-using-
saml.html
66
68. ユースケース: Web Identity Federation
• AssumeRoleWithWebIdentityの利用
– Web Identity Providerの認証を元に、AWSへのアクセスキーを発行
するサービス
• 認証を確認するサーバが不要
– 例えばスマートフォンアプリとS3だけでシステムが作成可能
• 現在Google,Facebook,Amazon(Login with Amazon), Amazon
Cognito及びOIDC準拠のIdPに対応
• IAM Roleを使用して実現
68
69. Web Identity Federationの動作
AWS Cloud
US-EAST-1
EU-WEST-1
AP-SOUTHEAST-1
AWS Services
Amazon
DynamoDB
S3
ユーザー認証
1
6
7
IAM
EC2
Instances
Tokenの
検証
4
Web identity
Provider
3
5
ポリシー
の確認
Id Token
の取得
2
Mobile App
http://aws.typepad.com/aws_japan/2013/05/aws-iam-now-supports-amazon-facebook-
and-google-identity-federation.html
69
70. OIDC-Based Web Identity Federation with Cognito
us-east-1
アプリケーション
Security
Token Service
DynamoDB
OpenID
Connect準拠の
IdP
2
4
STSの認証情報を用いて
AWSサービスにアクセス
リダイレクトして認証の実施
ID Tokenの取得
https://blogs.aws.amazon.com/security/post/Tx3LP54JOGBE0AY/Building-an-App-using-
Amazon-Cognito-and-an-OpenID-Connect-Identity-Provider
3
エンドユー
ザー
1
アプリケーションの利用
Cognito
Cognito tokenを用い
STSより認証情報の取得
Developer’s AWS Account
5
ID TokenからCognito
tokenの取得
70
73. IAMのベストプラクティス
1. AWS アカウント(ルート)のアクセスキーをロックする
2. 個々の IAM ユーザーを作成する
3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使う
4. 最小限の特権を認める
5. ユーザーのために強度の高いパスワードを設定する
6. 特権ユーザーに対して、MFA を有効化する
7. EC2で作動するアプリケーションに対し、ロールを使用する
8. 認証情報を共有するのではなく、ロールを使って委託する
9. 認証情報を定期的にローテーションする
10. 不要な認証情報の削除
11. 追加セキュリティに対するポリシー条件を使用する
12. AWSアカウントのアクティビティの履歴の保持
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/IAMBestPractices.html73
80. 次回のAWS Black Belt Tech Webinar は、
6月24日 18:00~
Amazon EC2 Container Service (ECS)
80