IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回

27,984 views

Published on

ほぼ週刊AWSマイスターシリーズでは、毎週テーマを決めて、各サービスの詳細情報を解説します。記念すべき第4回は、IAMとConsolidated Billingです

Published in: Technology

IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回

  1. 1. AWSマイスターシリーズ~IAM & Consolidated Billing~ 2011年10月19日 片山 暁雄( @c9katayama ) ソリューションアーキテクト
  2. 2. ほぼ週刊AWSマイスターシリーズへようこそ!~GoToMeetingの使い方~ 参加者は、自動的にミュートになっています 質問を投げることができます!  GoToMeetingの仕組みを使って、随時書き込んでください  ただし環境によっては、日本語の直接入力ができないので、 お手数ですが、テキストエディタ等に打ち込んでから、 貼り付けててください  最後のQ&Aの時間で、できるだけ回答させて頂きます  書き込んだ質問は、主催者にしか見えません Twitterのハッシュタグは#jawsugでどうぞ Copyright © 2011 Amazon Web Services
  3. 3. 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/
  4. 4. プレゼント本日一番良い質問を頂いた方に、 AWS特製 EC2帽子 (サイズ:m1.small)をプレゼントします!
  5. 5. Agenda IAMの概要 IAMの操作・設定方法 Identity Federation Consolidated Billing Consolidated Billingの使い方 まとめ Copyright © 2011 Amazon Web Services
  6. 6. IAMの概要
  7. 7. IAM(AWS Identity and Access Management) AWS利用者の認証と、アクセスポリシーを管理する仕組み  AWS操作のためのグループ・ユーザーの作成が可能  「EC2インスタンスの起動」や「このS3へのPUT」のような、AWS操作 に対するアクセス制御を行える ユーザーとグループで管理  ユーザーごとに認証情報の発行とアクセスポリシーの設定が可能  グループに対してアクセスポリシーを設定できる  グループにユーザーが所属できる • グループのポリシーを引き継ぐ 開発チーム 運用チーム
  8. 8. IAM(AWS Identity and Access Management) ユーザーごとに作成可能な認証情報  アクセスキー/シークレットキー  各種SDKのAPI利用時の認証に使用  セキュリティ証明書(X.509)  AMI-toolsなど特定の操作時の認証に使用  マネジメントコンソールへのログインパスワード  MFA(多要素認証)デバイス  マネジメントコンソールの認証要素 開発チーム AWS 運用チーム
  9. 9. IAM動作イメージ APIやマネジメントコンソールからの アクセスに対して、権限をチェック全操作可能S3はすべて操作可能S3参照だけ
  10. 10. ユースケースセキュリティの向上  IAMユーザーは簡単に無効化できるバックアップ専用ユーザー  EBSスナップショットのみ可能なユーザーでバックアップを実施  操作を誤ってもEC2を止めたり出来ないユーザーごとのS3バケット割り当て  1アカウントでS3を分割して使用できる
  11. 11. IAMの操作・設定方法
  12. 12. 操作・設定方法グループ・ユーザーの管理方法は以下の2つ  AWSマネジメントコンソールの利用  IAMのAPI実行アクセス権限の設定は「Access Policy Language」で記述  JSONフォーマットの記述式
  13. 13. マネジメントコンソール 「IAM」を選択グループとユーザーの 管理が可能
  14. 14. Access Policy Language{ "Statement": [ { "Effect": "Allow", "Action": [ " s3:ListBuckets ", " s3:Get * " ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:SourceIP": [“176.32.92.49/32“] } } } ]}
  15. 15. Access Policy Language{ "Statement": [ { "Effect": "Allow", "Action": [ " s3:ListBuckets ", " s3:Get * " ], "Resource": [ "*" この定義に従って、アクセス ], 可否を決定する "Condition": { "StringEquals": { "aws:SourceIP": [“176.32.92.49/32“] } } } ]}
  16. 16. アクセス制御の条件設定 { アクセス許可の設定なら”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系の操作を許可する」という意味
  17. 17. ActionとResource 「Action」は、操作自体に対する権限  RunInstances  AttachVolume  CreateBucket  DeleteObject 「Resource」は操作対象に対する権限  EC2インスタンス  EBSボリューム  S3バケット  S3オブジェクト
  18. 18. サービス毎の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 Elastic Load Balancing
  19. 19. 利用可能なConditionの構文 文字列  StringEquals,StringNotEquals, StringEqualsIgnoreCase  StringNotEqualsIgnoreCase,StringLike,StringNotLike 数値 日付 Bool IP Address  IpAddress  NotIpAddress
  20. 20. 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
  21. 21. マネジメントコンソールでのポリシー設定 テンプレートから選択 Policy Generatorを 使って作成 手動でポリシーを記述
  22. 22. Policy Generator
  23. 23. アクセス可否の決定ロジックアクセス制御の条件は複数設定可能  ユーザー・グループごとに条件が設定できるため、相反する条件 の設定も可能すべてのアクセスはデフォルトで拒否(デフォルトDeny)  アクセス権限に“Allow”の条件があった場合、アクセス許可  ただしアクセス権限に1つでも“Deny”の条件があった場合、アク セス拒否(明示的なDeny)  デフォルトDeny < Allow < 明示的なDeny グループのStatement グループのStatement Allow DenyAllow ユーザーのStatement ユーザーのStatement 該当しない Allow (デフォルトDeny) 結果:Allow 結果:Deny
  24. 24. ユーザーベースとリソースベース ポリシーは、ユーザーやグループ以外に、リソースにも紐付 け可能 S3バケット、SQSのキューに対してポリシーが適用可能  「特定のIPアドレスからしかアクセスできないバケット」など の設定が可能 北山 片山 酒井 ユーザーベース リソースベース
  25. 25. クロスアカウントアクセス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へのアクセス は不可
  26. 26. IAMユーザーでの管理コンソール利用マネジメントコンソールの専用URLからログイン「Account Alias」でユーザーフレンドリーな名前を指定可  ただしS3と同様早い者勝ち Account Alias利用 専用URL
  27. 27. 制約事項IAMユーザーではBillingを見ることは出来ません  全権限があっても、アカウントページへはログイン出来ません1AWSアカウントあたり、以下の制約があります  グループは100個まで  ユーザーは5000個まで  1ユーザーが所属できるグループは10個まで  ただし制限解除は可能
  28. 28. Identity Federation
  29. 29. Identity Federation 企業・組織の認証機能と、AWSの認証を紐づける機能 例えばLDAP認証したユーザーに対してS3のアクセス権をつ ける、といった連携が可能 認証したユーザー(Federatedユーザー)ごとに、一時的な AWS認証情報(Temporary Security Credentials)を発行
  30. 30. Temporary Security Credentials AWSに対する、一時的な認証情報を作成する仕組み  期限付きの認証情報(認証チケット) ユーザーに対して、以下の3つのキーを発行  アクセスID  シークレットキー  セッショントークン 作成した認証情報の有効期限設定が可能  デフォルト12時間 最小1時間 最大36時間  ただし延長・短縮は出来ない8
  31. 31. ユースケースモバイルアプリケーション  システムログインしたモバイルアプリユーザーごとにテンポラリの認 証情報を作成  モバイルから直接S3にアップロード可能  有効期限があるため、セキュア一時的なアクセス権限の譲渡  一時的にS3へアップロード出来るようなアプリケーションの作成  一時的にEC2を起動できるような仕組みの構築組織ユーザー毎のアクセス制御  ユーザーごとに利用できるS3バケットの作成  組織のグループに紐づけてアクセス制御を実施
  32. 32. 動作イメージWebアプリケーションで利用するケース
  33. 33. 動作イメージモバイルやクライアントアプリケーションで利用するケース
  34. 34. Identity Federation利用方法 アプリケーションから APIを使って連携 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
  35. 35. 制約事項対応サービス(2011/10現在)  EC2  S3  SQS  SNS  SimpleDBマネジメントコンソールへのログインは不可
  36. 36. Consolidated Billing
  37. 37. Consolidated Billing AWSの費用請求をまとめられるサービス 複数アカウントの費用を、1つにまとめて支払える 請求アカウント 全アカウントの費用が まとめて請求される 子アカウント 子アカウント
  38. 38. 利点支払いの一元化が可能アカウントごとの利用明細の確認が可能  部署ごと  プロジェクトごと通信量やデータ量は全アカウントを合算  合算後の量によっては、ボリュームディスカウントが可能リザーブドインスタンスの費用の融通が可能  あるアカウントで買ったリザーブドインスタンスを使っていな ければ、別のアカウントに自動でリザーブドの割引が適用
  39. 39. 利用までの流れ 請求アカウントを 決定 子アカウントに送られた メールで承諾 子アカウントを作成(既存アカウント可) 請求アカウントから 子カウントへ通知 コンソリデート成立(専用画面からメール 送付)
  40. 40. 利用までの流れ請求アカウントでログインし、「一括決済」を選択
  41. 41. 利用までの流れ子アカウントに対して、リクエストを送信
  42. 42. 利用までの流れ子アカウントに対して、リクエストを送信 子アカウントのメール アドレス
  43. 43. 利用までの流れ子アカウントにAWSからメールが配信される
  44. 44. 利用までの流れ子アカウントでリクエストを承認
  45. 45. 利用までの流れコンソリデート成立
  46. 46. コンソリ後請求アカウントに、子アカウントの費用が追加で表示される
  47. 47. まとめ
  48. 48. まとめIAMを使用すると、AWS操作の細かい制御が可能ユーザーを分けることで、よりセキュアに企業や組織の認証との連携も可能Consolidated Billingで費用支払いの一元化と、アカウント毎の明細の確認、ボリュームディスカウント可能
  49. 49. Q&ACopyright © 2011 Amazon Web Services
  50. 50. 次回のほぼ週刊AWSマイスターシリーズは、 10月26日 17:00~~ ELB, AutoScaling & CloudWatch ~ Copyright © 2011 Amazon Web Services
  51. 51. ご参加ありがとう ございました Copyright © 2011 Amazon Web Services

×