20120201 aws meister-reloaded-iam-and-billing-public

AWSマイスターシリーズ Reloaded
～IAM & Consolidated Billing～

2012年01月30日
片山暁雄（ @c9katayama ）
ソリューションアーキテクト

Agenda

IAMの概要
IAMの操作・設定方法
Identity Federation
Consolidated Billing
Consolidated Billingの使い方
まとめ

Copyright © 2011 Amazon Web Services

ＩＡＭ（AWS Identity and Access Management)

AWS利用者の認証と、アクセスポリシーを管理する仕組み
 AWS操作のためのグループ・ユーザーの作成が可能
 「EC2インスタンスの起動」や「このS3へのPUT」のような、AWS操作
に対するアクセス制御を行える

ユーザーとグループで管理
 ユーザーごとに認証情報の発行とアクセスポリシーの設定が可能
 グループに対してアクセスポリシーを設定できる
 グループにユーザーが所属できる
• グループのポリシーを引き継ぐ
開発チーム運用チーム

ＩＡＭ（AWS Identity and Access Management)
ユーザーごとに作成可能な認証情報
 アクセスキー/シークレットキー
 各種SDKのAPI利用時の認証に使用
 セキュリティ証明書(X.509)
 AMI-toolsなど特定の操作時の認証に使用
 マネジメントコンソールへのログインパスワード
 MFA(多要素認証)デバイス
 マネジメントコンソールの認証要素
開発チーム AWS 運用チーム

IAM動作イメージ APIやマネジメントコンソールからの
アクセスに対して、権限をチェック

全操作可能

S3はすべて
操作可能

S3参照だけ

ユースケース

セキュリティの向上
 IAMユーザーは簡単に無効化できる
バックアップ専用ユーザー
 EBSスナップショットのみ可能なユーザーでバックアップを実施
 操作を誤ってもEC2を止めたり出来ない
ユーザーごとのS3バケット割り当て
 1アカウントでS3を分割して使用できる

操作・設定方法

グループ・ユーザーの管理方法は以下の2つ
 AWSマネジメントコンソールの利用
 IAMのAPI実行

アクセス権限の設定は「Access Policy Language」で記述
 JSONフォーマットの記述式

マネジメントコンソール

「IAM」を選択

グループとユーザーの
管理が可能

Access Policy Language
{
"Statement": [
{
"Effect": "Allow",
"Action": [
" s3:ListBuckets ",
" s3:Get ＊ "
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:SourceIP": [“176.32.92.49/32“]
}
}
}
]
}

Access Policy Language
{
"Statement": [
{
"Effect": "Allow",
"Action": [
" s3:ListBuckets ",
" s3:Get ＊ "
],
"Resource": [
"*" この定義に従って、アクセス
], 可否を決定する
"Condition": {
"StringEquals": {
"aws:SourceIP": [“176.32.92.49/32“]
}
}
}
]
}

アクセス制御の条件設定
{
アクセス許可の設定なら”Allow”
"Effect": "Allow",
拒否の設定なら”Deny”
"Action": [
" s3:ListBuckets ",
対象となる操作を指定
" s3:Get ＊ " ワイルドカード使用可能
],
"Resource": [
対象となるリソースを指定
"*"
ARN(Amazon Resource Name）で記載
],
ワイルドカード使用可能
"Condition": {
"StringEquals": {
"aws:SourceIP": このアクセス制御が有効になる
[“176.32.92.49/32“] 条件の設定
}
}
} この例の場合、
「アクセス元IPが176.32.92.49だったら、S3の
ListBucketsとGet系の操作を許可する」という意味

ActionとResource

「Action」は、操作自体に対する権限
 RunInstances
 AttachVolume
 CreateBucket
 DeleteObject
「Resource」は操作対象に対する権限
 EC2インスタンス
 EBSボリューム
 S3バケット
 S3オブジェクト

サービス毎のAction/Resource利用可否
AWSサービス Action Resource
IAM
Amazon CloudFront
Amazon CloudWatch
EC2はResourceに
Amazon EC2
未対応のため、
Amazon ElastiCache
インスタンスやEBSごと
Amazon Elastic MapReduce の制御は行えない
Amazon RDS
Amazon Route 53
Amazon S3
Amazon SES
Amazon SimpleDB
Amazon SNS
Amazon SQS
Amazon VPC
Auto Scaling
AWS CloudFormation
AWS Elastic Beanstalk
Elastic Load Balancing

利用可能なConditionの構文

文字列
 StringEquals,StringNotEquals, StringEqualsIgnoreCase
 StringNotEqualsIgnoreCase,StringLike,StringNotLike
数値
日付
Bool
IP Address
 IpAddress
 NotIpAddress

Conditionの構文

"Condition" : {
"DateGreaterThan" : {
"aws:CurrentTime" : "2009-04-16T12:00:00Z"
AND
},
"DateLessThan": {
"aws:CurrentTime" : "2009-04-16T15:00:00Z"
},
AND "IpAddress" : {
"aws:SourceIp" : ["192.168.176.0/24","192.168.143.0/24"]
}
} OR

マネジメントコンソールでのポリシー設定

テンプレートから選択

Policy Generatorを
使って作成

手動でポリシーを記述

アクセス可否の決定ロジック
アクセス制御の条件は複数設定可能
 ユーザー・グループごとに条件が設定できるため、相反する条件
の設定も可能
すべてのアクセスはデフォルトで拒否(デフォルトDeny)
 アクセス権限に“Allow”の条件があった場合、アクセス許可
 ただしアクセス権限に１つでも“Deny”の条件があった場合、アク
セス拒否(明示的なDeny)
 デフォルトDeny < Allow < 明示的なDeny
グループのStatement グループのStatement
Allow DenyAllow

ユーザーのStatement ユーザーのStatement
該当しない
（デフォルトDeny)
Allow

結果：Allow 結果：Deny

ユーザーベースとリソースベース
ポリシーは、ユーザーやグループ以外に、リソースにも紐付
け可能
S3バケット、SQSのキューに対してポリシーが適用可能
 「特定のIPアドレスからしかアクセスできないバケット」など
の設定が可能

北山片山酒井

ユーザーベース
リソースベース

クロスアカウントアクセス

AWSアカウントを超してアクセスする事が可能

1.Account Aのバケットに以下のポリシーを設定
{
"Statement" : {
"Effect":"Allow",
"Principal" : {
"AWS":"AWS Account Bのアカウント番号"
},
"Action":"s3:*",
"Resource":"arn:aws:s3:::mybucket/*"
}
}

2.Account BでUser1を作り、mybucketへアクセス権限付与
User1がmybucketにアクセス可能になる

3.User2に権限を与えない場合は、mybucketへのアクセス
は不可

IAMユーザーでの管理コンソール利用
マネジメントコンソールの専用URLからログイン
「Account Alias」でユーザーフレンドリーな名前を指定可
 ただしS3と同様早い者勝ち

Account Alias利用

専用ＵＲＬ

制約事項

IAMユーザーではBillingを見ることは出来ません
 全権限があっても、アカウントページへはログイン出来ません
1AWSアカウントあたり、以下の制約があります
 グループは100個まで
 ユーザーは5000個まで
 1ユーザーが所属できるグループは10個まで
 ただし制限解除は可能

Identity Federation

企業・組織の認証機能と、AWSの認証を紐づける機能
例えばLDAP認証したユーザーに対してS3のアクセス権をつ
ける、といった連携が可能
認証したユーザー（Federatedユーザー）ごとに、一時的な
AWS認証情報（Temporary Security Credentials）を発行

Temporary Security Credentials
AWSに対する、一時的な認証情報を作成する仕組み
 期限付きの認証情報（認証チケット）
ユーザーに対して、以下の3つのキーを発行
 アクセスID
 シークレットキー
 セッショントークン
作成した認証情報の有効期限設定が可能
 デフォルト１２時間最小1時間最大36時間
 ただし延長・短縮は出来ない

8

ホテルに例えると・・・

AWS Account’s IAMユーザー Temporary Security
Access Key ID Credentials

IAMの権限階層
Permissions Example
すべての操作が可能 Action: *
Effect: Allow
Resource: *
AWS アカウント
(implicit)

ユーザーやグループ Action: [‘s3:*’,
‘sts:Get*’]
に対して割り当てら Effect: Allow
IAMユーザーれた権限 Resource: *

トークン作成時に決 Action: [ ‘s3:Get*’ ]
Temporary Effect: Allow
定される Resource:
Security
Credentials ‘arn:aws:s3:::mybucket/*’

ユースケース

モバイルアプリケーション
 システムログインしたモバイルアプリユーザーごとにテンポラリの認
証情報を作成
 モバイルから直接S3にアップロード可能
 有効期限があるため、セキュア
一時的なアクセス権限の譲渡
 一時的にS3へアップロード出来るようなアプリケーションの作成
 一時的にEC2を起動できるような仕組みの構築
組織ユーザー毎のアクセス制御
 ユーザーごとに利用できるS3バケットの作成
 組織のグループに紐づけてアクセス制御を実施

動作イメージ
Webアプリケーションで利用するケース

動作イメージ
モバイルやクライアントアプリケーションで利用するケース

Identity Federation利用方法アプリケーションから
ＡＰＩを使って連携
final String userId = request.getParameter("userId");
final String password = request.getParameter("password");
// 組織や企業でなにかしらの認証を実施
executeLDAPAuthentication(userId,password);

AWSCredentials credentials = new BasicAWSCredentials(IAMユーザーID,パスワード);
// SecurityTokenのクライアント
AWSSecurityTokenService securityTokenService =
new AWSSecurityTokenServiceClient(masterCredentials);

GetFederationTokenRequest req = new GetFederationTokenRequest();
req.setName(userId);
// S3 Read onlyの権限設定
req.setPolicy(“{”Statement“: [{”Effect“: ”Allow“,”Action“:
["s3:Get*","s3:List*"],"Resource":
"*"}]}");
// 認証情報の取得
GetFederationTokenResult result = securityTokenService.getFederationToken(req);
Credentials cs = result.getCredentials();
String tempAccessId = cs.getAccessKeyId();
String tempSecretkey = cs.getSecretAccessKey();
String sessionToken = cs.getSessionToken();

16

制約事項
Temporaryユーザー対応サービス(2012/1現在）

CloudFront S3
CloudWatch SimpleDB
DynamoDB(API Only) SQS
EC2 SNS
ElastiCache ELB
RDS Route53

Management Consoleへのログイン

Temporaryユーザー用のログインURL
 https://signin.aws.amazon.com/federation
以下の手順でログイン
 /federation?Action=getSigninToken&SessionType=json&Se
ssion={“sessionId”:””, ”sessionKey”:””, “sessionToken”:””}
 ログイン用トークンが戻ってくるので、再度下記URLにリダイレ
クト
 /federation?Action=login&SigninToken=ログイントークン
&Destination=マネジメントコンソールURL

Consolidated Billing

AWSの費用請求をまとめられるサービス
複数アカウントの費用を、1つにまとめて支払える

請求アカウント全アカウントの費用が
まとめて請求される

子アカウント

子アカウント

利点
支払いの一元化が可能
アカウントごとの利用明細の確認が可能
 部署ごと
 プロジェクトごと
通信量やデータ量は全アカウントを合算
 合算後の量によっては、ボリュームディスカウントが可能
リザーブドインスタンスの費用の融通が可能
 あるアカウントで買ったリザーブドインスタンスを使っていな
ければ、別のアカウントに自動でリザーブドの割引が適用

利用までの流れ

請求アカウントを
決定

子アカウントに送られた
メールで承諾
子アカウントを作成
（既存アカウント可）

請求アカウントから
子カウントへ通知
コンソリデート成立
（専用画面からメール
送付）

請求アカウントでログインし、「一括決済」を選択

子アカウントに対して、リクエストを送信

子アカウントに対して、リクエストを送信

子アカウントのメール
アドレス

子アカウントにＡＷＳからメールが配信される

子アカウントでリクエストを承認

コンソリデート成立

コンソリ後
請求アカウントに、子アカウントの費用が追加で表示される

まとめ

IAMを使用すると、AWS操作の細かい制御が可能
ユーザーを分けることで、よりセキュアに
企業や組織の認証との連携も可能
Consolidated Billingで費用支払いの一元化と、アカウント
毎の明細の確認、ボリュームディスカウント可能

20120201 aws meister-reloaded-iam-and-billing-public

More Related Content

What's hot (19)

Similar to 20120201 aws meister-reloaded-iam-and-billing-public (20)

More from Amazon Web Services Japan (20)

20120201 aws meister-reloaded-iam-and-billing-public