Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,553 views

Published on

Developers.IO 2018
IAM Overview and Best Practice

Published in: Technology
  • Be the first to comment

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

  1. 1. ビジネスを阻害しない AWS アカウントの管理 2018/10/5 Nobuhiro Nakayama
  2. 2. スライドは後で入手することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター音が出ないようにご配慮ください
  3. 3. 3今日のお題 Identity and Access Management (IAM)
  4. 4. 4今日のお題 IDと権限の管理
  5. 5. このセッションのゴール ⚫ IAMの基礎を理解する ⚫ IAMのベストプラクティスを知る ⚫ ベストプラクティスに準拠する具体的な方法 / 設定例を知る ⚫ 自分(の所属する組織)にとって「現実的な落としどころ」 を考える 5
  6. 6. 自己紹介 名前: 中山 順博 所属: AWS事業本部コンサルティング部 好きなAWSサービス: IAM, AWS CLI, Systems Manager 6
  7. 7. アジェンダ ⚫ IAMとは? ⚫ IAMのベストプラクティス ⚫ まとめ 7
  8. 8. アジェンダ ⚫ IAMとは? ⚫ IAMのベストプラクティス ⚫ まとめ 8
  9. 9. IAM とは? ⚫ AWSのリソースに安全にアクセスしてもらうための仕組み ⚫ 利用者を識別(ID管理) ⚫ 利用者の認証 ⚫ 利用者への権限付与(認可) 9
  10. 10. IAM の構成要素 ⚫ User ⚫ Group ⚫ Policy ⚫ Role 10
  11. 11. IAM User ⚫ AWSを操作するためのユーザー ⚫ 認証情報を設定 ⚫ コンソールにアクセスするためのログインパスワード ⚫ プログラムからアクセスするためのアクセスキー ⚫ 2つまで設定可能 ⚫ 認証要素として所有物認証を追加可能(多要素認証) ⚫ IAM Group のメンバーになることで権限を付与 ⚫ ユーザーに対して直接権限を付与することも可能 11
  12. 12. IAM Group ⚫ IAM Userをまとめる機能 ⚫ IAM Groupに対して権限を付与可能 ⚫ IAM Userをメンバーにすることでまとめて権限を付与 12
  13. 13. アクセスキー ⚫ アクセスキーとシークレットアクセスキーで構成 $ aws iam create-access-key --user-name xxxxxxxx { "AccessKey": { "UserName": “xxxxxxxx", "Status": "Active", "CreateDate": "2018-10-03T15:49:30Z", "SecretAccessKey": “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "AccessKeyId": “XXXXXXXXXXXXXXXXXXXX" } } 13
  14. 14. 多要素認証 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
  15. 15. 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": ["*"] } ] }
  16. 16. IAM Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"] }, { "Effect": "Deny", "Action": ["ec2:TerminateInstances"], "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } }, "Resource": ["*"] } ] } ⚫ Effect ⚫ ステートメントの結果を許可 または明示的な拒否のどちら にするかを指定 16
  17. 17. IAM Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"] }, { "Effect": "Deny", "Action": ["ec2:TerminateInstances"], "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } }, "Resource": ["*"] } ] } ⚫ Action ⚫ 許可または拒否される特定の アクションを指定 ⚫ ワイルドカード使用可能 17
  18. 18. IAM Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"] }, { "Effect": "Deny", "Action": ["ec2:TerminateInstances"], "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } }, "Resource": ["*"] } ] } ⚫ Resource ⚫ ステートメントで取り扱う一 連のオブジェクト ⚫ ARN (Amazon Resource Name) で指定 ⚫ ワイルドカード使用可能 ⚫ 例 ⚫ S3バケット 18
  19. 19. IAM Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"] }, { "Effect": "Deny", "Action": ["ec2:TerminateInstances"], "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } }, "Resource": ["*"] } ] } ⚫ Condition ⚫ ポリシーを実行するタイミン グの条件を指定 ⚫ 例 ⚫ リクエスト元IPアドレス ⚫ MFAデバイスでの認証 ⚫ タグ ⚫ 時刻 19
  20. 20. IAM Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"] }, { "Effect": "Deny", "Action": ["ec2:TerminateInstances"], "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
  21. 21. IAM Policy の種類 ⚫ 管理ポリシー ⚫ 独立したリソースとして定義できるポリシー ⚫ 再利用可能 ⚫ 5世代前までのポリシーを保持でき、ロールバック可能 ⚫ AWSによる定義済のポリシーが提供されている ⚫ インラインポリシー ⚫ User, Group, Roleに対して直接設定できるポリシー ⚫ (インラインポリシーを利用する機会は少ない) 21
  22. 22. IAM Role ⚫ AWSのサービス(EC2など)や他のAWSアカウントや Identity Provider (IdP) に権限を委任する仕組み ⚫ STS(Security Token Service)から一時的な認証情報を生成 ⚫ アクセスキーなど、永続的な認証情報を利用するよりセ キュアなシステム運用が可能 ⚫ Roleに設定されたPolicyの権限を取得できる ⚫ Roleに設定された信頼先からであれば一時認証情報を取得可 ⚫ Roleでは認証をしていない ⚫ 信頼先で認証されていることが前提 22
  23. 23. 一時的な認証情報を生成(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
  24. 24. 一時的な認証情報を生成(2/3) 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
  25. 25. 一時的な認証情報を生成(3/3) 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
  26. 26. アジェンダ ⚫ IAMとは? ⚫ IAMのベストプラクティス ⚫ まとめ 26
  27. 27. で、IAMの設計ってどうしたらいいの? ⚫ 組織がゼロからセキュリティポリシーを確立することは困難 ⚫ ベストプラクティス / フレームワークに則ることで効率的にセ キュアな運用設計を実現 ⚫ ただし、原理主義は禁物 ⚫ 原理主義に陥ると、開発スピード低下のリスクが 27 本日はAWSが提供するIAM ベストプラクティスを紹介 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
  28. 28. 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
  29. 29. 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 アカウントのアクティビティの監視 以下の3つに分類 •識別/ID管理 •認証 •認可/権限管理 29
  30. 30. 30 識別/ID管理
  31. 31. IAM ベストプラクティス(識別/ID管理) 1. 個々の IAM ユーザーの作成 2. AWS アカウントのアクティビティの監視 31
  32. 32. IAM ベストプラクティス(識別/ID管理) 1. 個々の IAM ユーザーの作成 2. AWS アカウントのアクティビティの監視 32
  33. 33. 個々の IAM ユーザーの作成 • ユーザーは必ず利用者個別に発行しましょう • 共有した場合、操作ログから「誰が」がわからない • 認証情報が漏洩した場合、認証情報を無効化しやすい • User や Group 別に権限を設定可能 33
  34. 34. IAM ベストプラクティス(識別/ID管理) 1. 個々の IAM ユーザーの作成 2. AWS アカウントのアクティビティの監視 34
  35. 35. AWS アカウントのアクティビティの監視 • AWSに対する操作を取得可能 • CloudTrailでAPI Callを記録 • 全てのリージョンで有効化 • ログ保存先のS3バケットのアクセスを制御 • 改ざんの有無を検証できるオプションを有効化 • ConfigでAWSリソース等の変更を記録 • IAMのリソースの変更も追跡可能 • 必要に応じてログの分析環境を準備 • 例 : Athena / QuickSight, CloudWatch Logs / Elasticsearch • 特定の操作をトリガに何らかの処理を実行することも可能 • CloudWatch Events + Lambda 35
  36. 36. CloudTrail 36
  37. 37. Config 37
  38. 38. 38 認証
  39. 39. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 39
  40. 40. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 40
  41. 41. AWS アカウントのルートユーザーのアクセスキーをロック • ルートユーザーとは • アカウント作成時に唯一存在するアカウント • 全ての権限を有する • 権限を制御できない • MFAの設定を強く推奨 • ルートユーザーでしかできない作業もある • 普段は利用しないことを推奨 • アクセスキーを発行できるが、無効化することを推奨 41
  42. 42. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 42
  43. 43. ユーザーの強力なパスワードポリシーを設定 • 使用できる文字の種別や長さ、再利用の条件などを指定可能 • 有効期限を設定した場合、 期限切れ後の初回ログインで再設定を要求 • ポリシーはアカウントの IAM User 全てに対して有効 • そもそも、認証要素がパスワードのみでは強度に限界 • 後述する多要素認証の利用を推奨 43
  44. 44. パスワードポリシー 44
  45. 45. 【補足】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. 46. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 46
  47. 47. 特権ユーザーに対して MFA を有効化する • 管理権限を持つIAM Userに追加することを強く推奨 • パスワードのみでは認証強度が不十分 • MFAの設定を各利用者に実施させることも可能 (必要なポリシーは後述) 47
  48. 48. 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. 49. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 49
  50. 50. 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
  51. 51. インスタンスメタデータから一時認証情報を取得 $ 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
  52. 52. 【補足】GuardDutyによる一時認証情報の不正利用検知 • GuardDuty で以下の Finding Type が提供されている • UnauthorizedAccess:IAMUser/InstanceCredential Exfiltration • EC2インスタンスに割り当てられたIAM Roleから取得さ れた一時認証情報が外部のIPアドレスから利用された場 合に通知(検知のみ) 52
  53. 53. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 53
  54. 54. ロールを使用したアクセス許可の委任 • EC2インスタンス以外にも権限を委任可能 • AWS Service • (CloudFormationの場合)Roleの権限でStackを作成 • 他のAWSアカウントやそのアカウントのIAM User • 例 : スイッチロール / Assume Role (他のアカウントへのアクセス) • 外部のIdP • 例 : IDフェデレーション • 応用例 • ロールの信頼ポリシーの条件でMFAを要求 • 「MFAを設定していないと特権(ロール)を利用できない」などを 実現可能 54
  55. 55. 【補足】スイッチロール 55 スイッチロール IAM User IAM Role AWS ID : 123456789012 AWS ID : 345678901234
  56. 56. 【補足】スイッチロール 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
  57. 57. 認証連携の仕組み 既存のユーザーのフェデレーション https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_identity-management.html#intro-identity-federation 57
  58. 58. 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. 59. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 59
  60. 60. アクセスキーを共有しない • 利用する場合は適切に管理する必要がある • アクセスキーを直接コードに埋め込まない • 異なるアプリケーションには、異なるアクセスキーを使用 • アクセスキーを定期的に更新 • 使用していないアクセスキーを削除 • (必要に応じて)多要素認証を設定 • IAM Userから永続的なアクセスキーを発行できるが、 可能な限りSTSから一時認証情報を生成して利用すべき AWS アクセスキーを管理するためのベストプラクティス https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-access-keys-best-practices.html 60
  61. 61. 漏洩事故は後を絶たず・・・ 61
  62. 62. awslabs/git-secrets • コードにアクセスキーがハードコードされてないかチェック するツールが提供されている • commit 時にスキャンしてくれる • commit 済のコードをスキャンすることも可能 awslabs/git-secrets https://github.com/awslabs/git-secrets 62 $ git secrets --scan
  63. 63. IAM ベストプラクティス(認証) 1. AWS アカウントのルートユーザーのアクセスキーをロック する 2. ユーザーの強力なパスワードポリシーを設定 3. 特権ユーザーに対して MFA を有効化する 4. Amazon EC2 インスタンスでロールを使用する 5. ロールを使用したアクセス許可の委任 6. アクセスキーを共有しない 7. 認証情報を定期的にローテーションする 8. 不要な認証情報を削除する 63
  64. 64. 認証情報を定期的にローテーションする • 永続的な認証情報を定期的に変更 • パスワード • アクセスキー • IAM Roleを利用していれば、 アクセスキーのローテーション自体不要 • コンソールや認証情報レポートで認証情報の古さを確認可能 64
  65. 65. 不要な認証情報を削除する • AWSへのアクセスが不要になった時点で削除 • 例 • 退職や異動 • システム / サブシステムの廃止 • プロジェクトの終了 • ID / 認証情報の削除が必要になるイベントを事前に定義 できているとベター • コンソールや認証情報レポートで認証の状況を確認可能 65
  66. 66. IAM Console (User) 66
  67. 67. 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
  68. 68. アクセスキーのローテーション 1. 新しいアクセスキーを作成 2. 新しいアクセスキーを設定 3. 古いアクセスキーを無効化 (問題が発生したら再アクティブ化) 4. 新しいアクセスキーが使用されていること、 古いアクセスキーが使用されなくなったことを確認 5. 古いアクセスキーを削除 68
  69. 69. 69 認可/権限管理
  70. 70. IAM ベストプラクティス(認可/権限管理) 1. IAM グループを使用する 2. AWS 定義のポリシーを使用して可能な限りアクセス権限を 割り当てる 3. 最小権限を付与する 4. アクセスレベルを使用して、IAM 権限を確認する 5. 追加セキュリティに対するポリシー条件を使用する 70
  71. 71. IAM ベストプラクティス(認可/権限管理) 1. IAM グループを使用する 2. AWS 定義のポリシーを使用して可能な限りアクセス権限を 割り当てる 3. 最小権限を付与する 4. アクセスレベルを使用して、IAM 権限を確認する 5. 追加セキュリティに対するポリシー条件を使用する 71
  72. 72. 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. 73. IAM ベストプラクティス(認可/権限管理) 1. IAM グループを使用する 2. AWS 定義のポリシーを使用して可能な限りアクセス権限を 割り当てる 3. 最小権限を付与する 4. アクセスレベルを使用して、IAM 権限を確認する 5. 追加セキュリティに対するポリシー条件を使用する 73
  74. 74. AWS 定義のポリシーを使用してアクセス権限を割り当て • AWS管理ポリシーを利用可能 • 機能別のポリシーと職務機能別のポリシーがある • サービスのアップデートに追従 • 開発環境や単一の目的で利用するAWSアカウントには適当 • ただし、ResourceやCondition等を利用した細かな制御はカ スタマー管理ポリシーを利用する必要がある • AWS管理ポリシーは全てのケースで適当という訳ではない • AWS管理ポリシーとカスタマー管理ポリシーの併用は可能 74
  75. 75. AWS管理ポリシー 75
  76. 76. IAM ベストプラクティス(認可/権限管理) 1. IAM グループを使用する 2. AWS 定義のポリシーを使用して可能な限りアクセス権限を 割り当てる 3. 最小権限を付与する 4. アクセスレベルを使用して、IAM 権限を確認する 5. 追加セキュリティに対するポリシー条件を使用する 76
  77. 77. 最小権限を付与する • 必要最低限の権限を最初に付与 + 必要に応じて権限を追加する アプローチを推奨 • Visual Editorを利用してポリシーを作成することが可能 • アクセスアドバイザーを利用していないサービスを確認可能 • 1つのアカウントを多目的に利用するとポリシーが複雑になりや すい • 目的別に複数のAWSアカウントを利用することでポリシーを シンプルにできる(場合がある) • 拠点とのVPN / 閉域接続が必要な場合にAWSアカウントを分 けるとネットワークの複雑性 / コストは増加する 77
  78. 78. Visual Editor 78
  79. 79. アクセスアドバイザー 79
  80. 80. IAM ベストプラクティス(認可/権限管理) 1. IAM グループを使用する 2. AWS 定義のポリシーを使用して可能な限りアクセス権限を 割り当てる 3. 最小権限を付与する 4. アクセスレベルを使用して、IAM 権限を確認する 5. 追加セキュリティに対するポリシー条件を使用する 80
  81. 81. アクセスレベルを使用して、IAM 権限を確認する • アクションは以下の5つのレベルに分類 • List, Read, Write, Permissions management, or Tagging • ポリシーの概要でポリシーにどのレベルのアクションが許可されているか 確認可能 • まずは概要を確認し、必要に応じてAction単位で確認 • 同じレベルでもサービスによって意味が大きく異なるケースがあるので注 意 • AWS管理ポリシー”ReadOnlyAccess”では ”S3:GetObject”が許可 • S3などで機密性の高いデータを保存している場合に注意 • EC2などとのReadとは別物 81
  82. 82. ポリシー概要 82
  83. 83. IAM ベストプラクティス(認可/権限管理) 1. IAM グループを使用する 2. AWS 定義のポリシーを使用して可能な限りアクセス権限を 割り当てる 3. 最小権限を付与する 4. アクセスレベルを使用して、IAM 権限を確認する 5. 追加セキュリティに対するポリシー条件を使用する 83
  84. 84. 追加セキュリティに対するポリシー条件を使用する • Conditionを利用することできめ細かな制御が可能 • リクエスト送信元IPアドレス • MFA認証の有無 • 時刻 • リソースに付与されたタグ • ・・・など 84
  85. 85. 【補足】 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
  86. 86. 【補足】 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
  87. 87. 【補足】 時刻を条件に利用したポリシー { "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
  88. 88. 【補足】 タグを条件に利用したポリシー { "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
  89. 89. 【利用例】 特権を一時的に付与する承認ワークフロー • 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
  90. 90. 【おまけ】準拠状況を継続的にチェックしたい ⚫ Insightwatchである程度準拠状況をチェック可能 ⚫ 以下の事項はチェックでしきれない ⚫ 個々のIAM Userの利用 / アクセスキーの共有 ⚫ 発行されたものが共有されているかはわからない ⚫ 最小権限の付与 / ポリシー条件の使用 ⚫ 必要な権限は要件次第なので一概に妥当性を判断できない ⚫ ツールでできること / できないことを正しく理解して使いま しょう 90
  91. 91. アジェンダ ⚫ IAMとは? ⚫ IAMのベストプラクティス ⚫ まとめ 91
  92. 92. まとめ ⚫ 利用者 / 目的別にIDを発行しましょう ⚫ 監査可能な環境を構築 ⚫ すでに Identity Provider がある場合には認証連携を検討 (IDの二重管理を回避) ⚫ 適切な強度の認証を ⚫ 最低でも管理者には多要素認証を設定 ⚫ 可能な限り一時的な認証情報を利用 ⚫ 権限を可能な範囲で最小化 ⚫ AWSが提供するポリシーを最大限活用 ⚫ 必要に応じてマルチアカウントで権限分離 ⚫ 原理主義に陥らず、受容可能なリスクの見極めよう 92
  93. 93. 93

×