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

2011年10月19日

片山 暁雄（ @c9katayama ） ソリューションアーキテクト

ほぼ週刊AWSマイスターシリーズへようこそ！ ~GoToMeetingの使い方～

参加者は、自動的にミュートになっています

質問を投げることができます！

GoToMeetingの仕組みを使って、随時書き込んでください

ただし環境によっては、日本語の直接入力ができないので、

お手数ですが、テキストエディタ等に打ち込んでから、

貼り付けててください

最後のＱ＆Ａの時間で、できるだけ回答させて頂きます

書き込んだ質問は、主催者にしか見えません

Twitterのハッシュタグは#jawsugでどうぞ

Copyright © 2011 Amazon Web Services

Webセミナー

ほぼ週刊AWSマイスターシリーズ（全10回） 10/19 第4回 IAM & Consolidated Billing

10/26 第5回 ELB, AutoScaling & CloudWatch

11/1 第6回 CloudFormation

11/9 第7回 VPC

11/16 第8回 RDS

11/22 第9回 EMR

11/30 第10回 SES

http://aws.amazon.com/jp/event_schedule/ 申し込みサイト

プレゼント

本日一番良い質問を頂いた方に、

ＡＷＳ特製 ＥＣ２帽子 （サイズ：m1.small)

をプレゼントします！

Agenda

IAMの概要

IAMの操作・設定方法

Identity Federation

Consolidated Billing

Consolidated Billingの使い方

まとめ

Copyright © 2011 Amazon Web Services

IAMの概要

ＩＡＭ（AWS Identity and Access Management)

AWS利用者の認証と、アクセスポリシーを管理する仕組み

AWS操作のためのグループ・ユーザーの作成が可能

「EC2インスタンスの起動」や「このS3へのPUT」のような、AWS操作に対するアクセス制御を行える

ユーザーとグループで管理

ユーザーごとに認証情報の発行とアクセスポリシーの設定が可能

グループに対してアクセスポリシーを設定できる

グループにユーザーが所属できる

• グループのポリシーを引き継ぐ

開発チーム 運用チーム

AWS 開発チーム

ＩＡＭ（AWS Identity and Access Management)

ユーザーごとに作成可能な認証情報

アクセスキー/シークレットキー

各種SDKのAPI利用時の認証に使用

セキュリティ証明書(X.509)

AMI-toolsなど特定の操作時の認証に使用

マネジメントコンソールへのログインパスワード

MFA(多要素認証)デバイス

マネジメントコンソールの認証要素

運用チーム

IAM動作イメージ APIやマネジメントコンソールからの

アクセスに対して、権限をチェック

全操作可能

S3はすべて操作可能

S3参照だけ

ユースケース

セキュリティの向上

IAMユーザーは簡単に無効化できる

バックアップ専用ユーザー

EBSスナップショットのみ可能なユーザーでバックアップを実施

操作を誤ってもEC2を止めたり出来ない

ユーザーごとのS3バケット割り当て

1アカウントでS3を分割して使用できる

IAMの操作・設定方法

操作・設定方法

グループ・ユーザーの管理方法は以下の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“]

}

}

}

]

}

この定義に従って、アクセス可否を決定する

アクセス制御の条件設定

{

"Effect": "Allow",

"Action": [

" s3:ListBuckets ",

" s3:Get ＊ "

],

"Resource": [

"*"

],

"Condition": {

"StringEquals": {

"aws:SourceIP":

[“176.32.92.49/32“]

}

}

}

アクセス許可の設定なら”Allow”

拒否の設定なら”Deny”

対象となる操作を指定

ワイルドカード使用可能

対象となるリソースを指定

ARN(Amazon Resource Name）で記載

ワイルドカード使用可能

このアクセス制御が有効になる

条件の設定

この例の場合、

「アクセス元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

Amazon EC2

Amazon ElastiCache

Amazon Elastic MapReduce

Amazon RDS

Amazon Route 53

Amazon S3

Amazon SES

Amazon SimpleDB

Amazon SNS

Amazon SQS

Amazon VPC

Auto Scaling

AWS CloudFormation

Elastic Load Balancing

EC2はResourceに

未対応のため、

インスタンスやEBSごとの制御は行えない

利用可能なConditionの構文

文字列

StringEquals,StringNotEquals, StringEqualsIgnoreCase

StringNotEqualsIgnoreCase,StringLike,StringNotLike

数値

日付

Bool

IP Address

IpAddress

NotIpAddress

Conditionの構文

"Condition" : {

"DateGreaterThan" : {

"aws:CurrentTime" : "2009-04-16T12:00:00Z"

},

"DateLessThan": {

"aws:CurrentTime" : "2009-04-16T15:00:00Z"

},

"IpAddress" : {

"aws:SourceIp" : ["192.168.176.0/24","192.168.143.0/24"]

}

} OR

AND

AND

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

Policy Generatorを

使って作成

手動でポリシーを記述

テンプレートから選択

Policy Generator

ユーザーのStatement ユーザーのStatement

アクセス可否の決定ロジック

アクセス制御の条件は複数設定可能

ユーザー・グループごとに条件が設定できるため、相反する条件の設定も可能

すべてのアクセスはデフォルトで拒否(デフォルトDeny)

アクセス権限に“Allow”の条件があった場合、アクセス許可

ただしアクセス権限に１つでも“Deny”の条件があった場合、アクセス拒否(明示的なDeny)

デフォルトDeny < Allow < 明示的なDeny

グループのStatement

Allow

該当しない

（デフォルトDeny)

結果：Allow

Allow

Allow

結果：Deny

グループのStatement

Deny

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

ポリシーは、ユーザーやグループ以外に、リソースにも紐付け可能

S3バケット、SQSのキューに対してポリシーが適用可能

「特定のIPアドレスからしかアクセスできないバケット」などの設定が可能

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

片山 北山 酒井

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

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

{

"Statement" : {

"Effect":"Allow",

"Principal" : {

"AWS":"AWS Account Bのアカウント番号"

},

"Action":"s3:*",

"Resource":"arn:aws:s3:::mybucket/*"

}

}

1.Account Aのバケットに以下のポリシーを設定

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

Identity Federation

企業・組織の認証機能と、AWSの認証を紐づける機能

例えばLDAP認証したユーザーに対してS3のアクセス権をつける、といった連携が可能

認証したユーザー（Federatedユーザー）ごとに、一時的なAWS認証情報（Temporary Security Credentials）を発行

Temporary Security Credentials

AWSに対する、一時的な認証情報を作成する仕組み

期限付きの認証情報（認証チケット）

ユーザーに対して、以下の3つのキーを発行 アクセスID

シークレットキー

セッショントークン

作成した認証情報の有効期限設定が可能 デフォルト１２時間 最小1時間 最大36時間

ただし延長・短縮は出来ない

8

ユースケース

モバイルアプリケーション

システムログインしたモバイルアプリユーザーごとにテンポラリの認証情報を作成

モバイルから直接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

アプリケーションから

ＡＰＩを使って連携

制約事項

対応サービス(2011/10現在）

EC2

S3

SQS

SNS

SimpleDB

マネジメントコンソールへのログインは不可

Consolidated Billing

Consolidated Billing

AWSの費用請求をまとめられるサービス

複数アカウントの費用を、1つにまとめて支払える

請求アカウント

子アカウント

子アカウント

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

利点

支払いの一元化が可能

アカウントごとの利用明細の確認が可能

部署ごと

プロジェクトごと

通信量やデータ量は全アカウントを合算

合算後の量によっては、ボリュームディスカウントが可能

リザーブドインスタンスの費用の融通が可能

あるアカウントで買ったリザーブドインスタンスを使っていなければ、別のアカウントに自動でリザーブドの割引が適用

利用までの流れ

請求アカウントを

決定

子アカウントを作成

（既存アカウント可）

請求アカウントから

子カウントへ通知

（専用画面からメール送付）

子アカウントに送られたメールで承諾

コンソリデート成立

利用までの流れ

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

利用までの流れ

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

利用までの流れ

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

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

利用までの流れ

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

利用までの流れ

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

利用までの流れ

コンソリデート成立

コンソリ後

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

まとめ

まとめ

IAMを使用すると、AWS操作の細かい制御が可能

ユーザーを分けることで、よりセキュアに

企業や組織の認証との連携も可能

Consolidated Billingで費用支払いの一元化と、アカウント毎の明細の確認、ボリュームディスカウント可能

Q & A

Copyright © 2011 Amazon Web Services

次回の

ほぼ週刊AWSマイスターシリーズは、

10月26日 17:00～

～ ELB, AutoScaling & CloudWatch ～

Copyright © 2011 Amazon Web Services

ご参加ありがとう ございました

Copyright © 2011 Amazon Web Services