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.

PCI DSSにおける認証認可 インフラ編

359 views

Published on

PCI DSSにおける認証認可 インフラ編

Published in: Technology
  • Be the first to comment

  • Be the first to like this

PCI DSSにおける認証認可 インフラ編

  1. 1. PCI DSSにおける認証認可 インフラ編 クラスメソッド株式会社 AWS事業本部 2019/09/24 Nobuhiro Nakayama 1
  2. 2. 2目次 PCI DSSにおける認証・認可の要件 AWSにおける認証・認可
  3. 3. 3 PCI DSSにおける認証・認可の要件
  4. 4. 4 要件7および8
  5. 5. 5 要件 7: カード会員データへのアクセスを 業務上必要な範囲内に制限する(認可)
  6. 6. 6 要件 8: システムコンポーネントへの アクセスを識別・認証する
  7. 7. 7要件 7: カード会員データへのアクセスを業務上必要な範囲内に制限する 7.1 システムコンポーネントとカード会員データへのアクセスを、業務上必要な人に限定す る。 • 7.1.1 以下を含む、各役割のアクセスニーズを定義する • 各役割が職務上アクセスする必要のあるシステムコンポーネントとデータリソース • リソースへのアクセスに必要な特権レベル(ユーザ、管理者など) • 7.1.2 特権ユーザ ID に与えるアクセス権を職務の実行に必要な最小限の特権に制限する • 7.1.3 個人の職種と職務に基づくアクセス権を割り当てる。 • 7.1.4 適切な権限を持つ関係者による文書化された変更承認を必要とする。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library
  8. 8. 8要件 7: カード会員データへのアクセスを業務上必要な範囲内に制限する 7.2 システムコンポーネントのアクセス制御システムを確立することで、ユーザの必要性に 基づいてアクセスを制限し、特に許可のない場合は「すべてを拒否」に設定する。アクセス 制御システムには以下の項目を含める必要がある。 • 7.2.1 すべてのシステムコンポーネントを対象に含む • 7.2.2 職種と職務に基づく、個人への特権の付与 • 7.2.3 デフォルトでは「すべてを拒否」の設定 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library
  9. 9. 9要件 7: カード会員データへのアクセスを業務上必要な範囲内に制限する 7.3 カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が文 書化されて使用されており、影響を受ける関係者全員に知られていることを、確実にする。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library 今日の勉強会のスコープ外
  10. 10. 10要件 8: システムコンポーネントへのアクセスを識別・認証する 8.1 ポリシーと手順を定義して実装することで、次のように、すべてのシステム コンポー ネントで、非消費者ユーザと管理者のための適切なユーザ識別管理が行 われるようにする。 • 8.1.1 システムコンポーネントまたはカード会員データへのアクセスを許可する前に、すべてのユーザ に一意の IDを割り当てる。 • 8.1.2 ユーザ ID、資格情報、およびその他の識別オブジェクトの追加、削除、変更を管理する。 • 8.1.3 契約終了したユーザのアクセスを直ちに取り消す。 • 8.1.4 90 日以内に非アクティブなユーザアカウントを削除/無効にする。 • 8.1.5 第三者がリモートアクセス経由でシステムコンポーネントのアクセス、サポート、メンテナンス に使用するユーザID を以下のように管理する。 • 必要な期間内だけ有効になり、使用されていないときは無効になっている。 • 使用時に監視されている。 • 8.1.6 6 回以下の試行で、ユーザ ID をロックアウトすることによって、アクセス試行の繰り返しを制 限する。 • 8.1.7 最低 30 分間、または管理者がユーザ ID を有効にするまでのロックアウト期間を設定する。 • 8.1.8 セッションのアイドル状態が 15分を超えた場合、ターミナルまたはセッションを再度アクティ ブにするため、ユーザの再認証が必要となる。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library
  11. 11. 11要件 8: システムコンポーネントへのアクセスを識別・認証する 8.2 一意の ID を割り当てることに加え、すべてのユーザを認証するため、次の方法の少な くとも 1 つを使用することで、すべてのシステムコンポーネント上での非消費者のユーザ と管理者の適切なユーザ認証管理を確実にする。※認証の3要素:知識、所有、生体 • 8.2.1 強力な暗号化を使用して、すべてのシステムコンポーネントで、送信と保存中に認証情報(パス ワード/パスフレーズなど)をすべて読み取り不能とする。 • 8.2.2 パスワードのリセット、新しいトークンの準備、新しい鍵の生成など、認証情報を変更する前に、 ユーザの身元を確認する。 • 8.2.3 パスワード/パスフレーズは以下を満たす必要がある。 • パスワードに 7 文字以上が含まれる • 数字と英文字の両方を含むあるいは、上記のパラメータに等しい複雑さと強度をもつパスワード/パスフレーズ • 8.2.4 ユーザパスワード/パスフレーズは、少なくとも 1 回は 90 日ごと変更する。 • 8.2.5 これまでに使用した最後の 4 つのパスワード/パスフレーズのいずれかと同じである新しいパス ワード/パスフレーズを許可しない。 • 8.2.6 初期パスワード/パスフレーズとリセットパスワード/パスフレーズをユーザごとに一意の値にリ セットし、初回の使用後直ちに変更する。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library
  12. 12. 12要件 8: システムコンポーネントへのアクセスを識別・認証する 8.3 CDE に対する、すべての非コンソール管理アクセス、ならびにすべてのリモートアク セスについて、多要素認証を使用して安全に保護する。 • 8.3.1 CDE への管理者のアクセス権を持つ担当者によるすべての非コンソールアクセスに多要素認証 を組み込む。 • 8.3.2 事業体のネットワーク外からのすべてのリモートネットワークアクセス(ユーザと管理者の両方、 サポートやメンテナンスのための第三者のアクセスを含む)に多要素認証を組み込む。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library
  13. 13. 13要件 8: システムコンポーネントへのアクセスを識別・認証する 8.4 以下を含む認証のポリシーと手順を文書化し、すべてのユーザに通達する。 • 強力な認証情報を選択するためのガイダンス • ユーザが自分の認証情報を保護する方法についてのガイダンス • 前に使用していたパスワードを再使用しないという指示 • パスワードが侵害された疑いがある場合にはパスワードを変更するという指示 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library 今日の勉強会のスコープ外
  14. 14. 14要件 8: システムコンポーネントへのアクセスを識別・認証する 8.5 次のように、グループ、共有、または汎用の ID やパスワード、または他の認証方法が 使用されていない。 • 汎用ユーザ ID が無効化または削除されている • システム管理作業およびその他の重要な機能に対する共有ユーザ ID が存在しない • システムコンポーネントの管理に共有および汎用ユーザ ID が使用されていない • 8.5.1 サービスプロバイダのみの追加要件: 顧客環境へのリモートアクセス権を持つサービスプロバイダは(例:POS システムやサーバのサポー トで)、各顧客に一意な認証情報(パスワード/パスフレーズなど)を使用する必要がある。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library 今日の勉強会のスコープ外
  15. 15. 15要件 8: システムコンポーネントへのアクセスを識別・認証する 8.6 その他の認証メカニズムが使用されている(例えば、物理的または論理的セキュリティ トークン、スマートカード、証明書など)これらのメカニズムの使用は、以下のように割り 当てる必要がある。 • 認証メカニズムは、個々のアカウントに割り当てなければならず、複数アカウントで共有するこ とはできない • 物理/論理制御により、意図されたアカウントのみがアクセスできるようにする必要がある Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library 今日の勉強会のスコープ外
  16. 16. 16要件 8: システムコンポーネントへのアクセスを識別・認証する 8.7 カード会員データを含むデータベースへのすべてのアクセス(アプリケーション、管理 者、およびその他のすべてのユーザによるアクセスを含む)が以下のように制限されている。 • データベースへのユーザアクセス、データベースのユーザクエリ、データベースに対するユーザ アクションはすべて、プログラムによる方法によってのみ行われる。 • データベースへの直接アクセスまたはクエリはデータベース管理者のみに制限される。 • データベースアプリケーション用のアプリケーション ID を使用できるのはそのアプリケーショ ンのみである(個々のユーザやその他の非アプリケーションプロセスは使用できない)。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library
  17. 17. 17要件 8: システムコンポーネントへのアクセスを識別・認証する 8.8 識別と認証に関するセキュリティポリシーと操作手順が文書化されて使用されており、 影響を受ける関係者全員に知られていることを、確実にする。 Payment Card Industry(PCI) データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018 年 5 月 https://www.pcisecuritystandards.org/document_library 今日の勉強会のスコープ外
  18. 18. 18まとめると・・・ 7.1: 権限を付与する対象の最小化 7.2: 権限(ポリシー)の最小化 7.3: 適切な権限の明文化と周知 8.1: 厳格な識別、不正な第三者の排除 8.2: (パスワードの)認証強度の確保 8.3: 多要素認証の実装 8.4: 認証方法の明文化と周知 8.5: IDの共有禁止 8.6: 認証要素(トークン、証明書など)の共有禁止 8.7: データベースアクセスの制限 8.8: セキュリティポリシーの明文化と周知
  19. 19. 19 サービスとしてのAWSが どの程度要件を未対しているのか?
  20. 20. 20 AWSにおける認証・認可
  21. 21. 21 7.1: 権限を付与する対象の最小化
  22. 22. 22 アクセスニーズの定義
  23. 23. 23アクセスアドバイザーによる利用サービスの特定 サービスの最終アクセス時間データを表示
  24. 24. 24CloudTrailによる証跡の保存 アカウントアクティビティをログに記録
  25. 25. 25Athenaによる証跡の分析 保存先のS3BucketをLOCATIONで指定し、ログファイルを 直接クエリ • すべての匿名 (署名されていない) リクエストを返すの例 SELECT * FROM cloudtrail_logs WHERE eventsource = 's3.amazonaws.com' AND eventname in ('GetObject') AND useridentity.accountid LIKE '%ANONYMOUS%' AND useridentity.arn IS NULL AND requestparameters LIKE '%[your bucket name ]%'; Querying AWS CloudTrail Logs https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
  26. 26. 26 最小限の特権に制限
  27. 27. 27 職務定義のはなしなので割愛
  28. 28. 28 個人の職種と職務に基づく アクセス権の割り当て
  29. 29. 29IAM Userに対するアクセス制御 権限付与の方法 • 【非推奨】IAM Userに権限を付与 • IAM Groupに権限を付与してIAM Userを参加させる • IAM Roleに権限を付与してIAM Userを信頼 • Assume Roleで一時的な認証情報を取得できる その他の制御方法 • Organizations SCPによるAWSアカウント横断のアクセス制御 • Permission BoundaryでIAM管理権限の「範囲」を制御
  30. 30. 30 変更の承認
  31. 31. 31Systems Manager Automation SSM Documentで承認アクションを記述可能 • 「指定されたプリンシパルによってアクションか承認または拒否さ れるまで、一時的に自動化の実行を停止」 任意のAPIへリクエスト可能 • PolicyのアタッチやCFnスタックの更新など • SSM Documentとして定型化できるかがポイント • https://docs.aws.amazon.com/systems-manager/latest/userguide/automation- actions.html#automation-action-executeAwsApi
  32. 32. 32承認アクションの例 mainSteps: - name: approve action: aws:approve timeoutSeconds: 1000 onFailure: Abort inputs: NotificationArn: arn:aws:sns:us-east-2:12345678901:AutomationApproval Message: "{{ message }}" MinRequiredApprovals: 1 Approvers: - arn:aws:iam::12345678901:user/AWS-User-1 - name: run action: aws:runCommand aws:approve https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/automation-actions.html#automation-action-approve
  33. 33. 33 7.2: 権限(ポリシー)の最小化
  34. 34. 34 すべてのシステムコンポーネントが 制御の対象
  35. 35. 35IAM Policyによるアクセス制御 Principal, Resource, Actionなどの要素で詳細な制御が可能 • PrincipalはIdentity-based policyでは利用できない(リソースポ リシーなどで利用) • Condition要素で、さらに細かい制御も可能 • 時刻、MFAの有無、接続元のIPアドレス、など
  36. 36. 36Identity-based policyの例 一つのPolicyに複数のStatementを定義可能 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "rds:*", "Resource": ["arn:aws:rds:region:*:*"] }, { "Effect": "Allow", "Action": ["rds:Describe*"], "Resource": ["*"] } ] } Amazon RDS: Allows Full RDS Database Access Within a Specific Region https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_rds_region.html
  37. 37. 37Resource-based policyの例 { "Version":"2012-10-17", "Statement":[ { "Sid":"AddCannedAcl", "Effect":"Allow", "Principal": {"AWS": ["arn:aws:iam::111122223333:root","arn:aws:iam::444455556666:root"]}, "Action":["s3:PutObject","s3:PutObjectAcl"], "Resource":["arn:aws:s3:::examplebucket/*"], "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}} } ] } Granting Permissions to Multiple Accounts with Added Conditions https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html#example-bucket-policies-use-case-1
  38. 38. 38OSおよびRDBMSへのアクセス EC2やRDSのインスタンス「内」に対するアクセス制御 • RDSに対してデータベースへ接続するための認証トークンの発行を 要求できる • データベース側で認証情報を管理する必要がない • RDS for MySQL / PostgreSQLでサポート • Systems Manager Session Managerを利用することで、パスワー ド/SSHキーなしにShellへのアクセスが可能
  39. 39. 39IAM Policy for IAM Database Access(例) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds-db:connect" ], "Resource": [ "arn:aws:rds-db:us-east-2:1234567890:dbuser:db-ABCDEFGHIJKL01234/db_user" ] } ] } Creating and Using an IAM Policy for IAM Database Access https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html
  40. 40. 40IAM Policies for Session Manager(例) { "Effect": "Allow", "Action": [ "ssm:StartSession" ], "Resource": [ "arn:aws:ec2:us-east-2:123456789012:instance/i-1234567890EXAMPLE", "arn:aws:ec2:us-east-2:123456789012:instance/i-abcdefghijEXAMPLE", "arn:aws:ec2:us-east-2:123456789012:instance/i-0e9d8c7b6aEXAMPLE" ] }, { "Effect": "Allow", "Action": [ "ssm:TerminateSession" ], "Resource": [ "arn:aws:ssm:*:*:session/${aws:username}-*" ] } Additional Sample IAM Policies for Session Manager (Example 1: Restrict Access to Specific Instances) https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-restrict-access-examples.html
  41. 41. 41 (正しく)個人への特権の付与
  42. 42. 42設計通りに構成されていることをテスト 事前評価 • CloudFormationやTerraformのコードレビュー 事後評価 • IAM Policy Simulator • https://policysim.aws.amazon.com/ • awspec (OSS) • https://github.com/k1LoW/awspec • IAMの各種リソースをサポート
  43. 43. 43Awspec / belong_to_iam_group IAM Userが特定のIAM Groupに所属していることを評価す る例 describe iam_user('my-iam-user') do it { should belong_to_iam_group('my-iam-group') } end belong_to_iam_group https://github.com/k1LoW/awspec/blob/master/doc/resource_types.md#belong_to_iam_group
  44. 44. 44 デフォルトでは「すべてを拒否」
  45. 45. 45IAMの認可はDefault Deny 何も許可しなければ何もできない Policy Evaluation Logic https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
  46. 46. 46 8.1: 厳格な識別、不正な第三者の排除
  47. 47. 47 すべてのユーザに一意のIDを割り当て
  48. 48. 48所有物による認証 知識(パスワード)だけでは共有/漏洩のリスクが大きい 以下のMFAデバイスをサポート • Virtual MFA device • U2F security key • Hardware-based MFA device
  49. 49. 49IAM Roleが権限を委任する条件にMFAを追加
  50. 50. 50 ユーザ ID、資格情報、およびその他の 識別オブジェクトの追加、削除、変更を管理
  51. 51. 51AWS ConfigによるIAM Entityの構成管理
  52. 52. 52AWS ConfigによるIAM Entityの構成管理 認証情報の発行 (グループへの追加に伴う) 権限の不要
  53. 53. 53 契約終了したユーザのアクセスを 直ちに取り消す
  54. 54. 54SAML/OIDCをサポートするIdPとの認証連携 ディレクトリのユーザーが契約の状態を反映しているのであれ ば、迅速にユーザーを取り消せる 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/
  55. 55. 55 90 日以内に非アクティブな ユーザアカウントを削除/無効
  56. 56. 56IAM Userの最終ログイン日時を確認 IAM Userの属性として確認可能 • Credential Reportでも確認可能 $ aws iam get-user --user-name (user name) { "User": { "UserName": “(user name)", "PasswordLastUsed": "2019-01-11T09:24:09Z", "CreateDate": "2017-09-26T01:17:46Z", "UserId": "AXXXXXXXXXXXXXXXXXXXX", "Path": "/", "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/(user name)" } } get-user https://docs.aws.amazon.com/cli/latest/reference/iam/get-user.html
  57. 57. 57Automated IAM User Cleanup Level 200: Automated IAM User Cleanup: Lab Guide https://github.com/awslabs/aws-well-architected-labs/blob/master/Security/200_Automated_IAM_User_Cleanup/Lab_Guide.md
  58. 58. 58Automated IAM User Cleanup
  59. 59. 59 「必要な期間内だけ有効」 「使用時に監視」
  60. 60. 60IAM Policyの条件に時刻を利用 グローバル条件キーとして以下のキーを利用可能 • aws:CurrentTime, aws:EpochTime { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "service-prefix:action-name", "Resource": "*", "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"}, "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"} } } } AWS: Allows Access Within Specific Dates https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws-dates.html
  61. 61. 61 IAMユーザーに特権を一時的に付与する簡易承認ワークフローをSystems Manager (Automation) で実装してみた https://dev.classmethod.jp/cloud/aws/workflow-to-add-temporary-privilege-by-ssm-automation/
  62. 62. 62 ユーザ ID をロックアウト
  63. 63. 63 CloudTrailで認証の失敗や権限の無いアクションが時効され たことを記録することが可能 • CloudWatch Logsでメトリクスフィルタを定義して通知すること が可能(ただし、リアルタイムではない) • 例 : コンソールサインインの失敗 • https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudwatch- alarms-for-cloudtrail.html#cloudwatch-alarms-for-cloudtrail-signin • ロックアウトの処理までは標準実装されていない • CloudWatch Alarm > SNS > Lambda のように実装することは可能 • ロックアウトを解除するロジックも別途実装する必要がある
  64. 64. 64 セッションのアイドル状態が 15分を超えた場合、ユーザの再認証が必要
  65. 65. 65Assume Roleで発行する認証情報の有効期間 IAM Roleで発行する一時認証情報の有効期間を制限できる • デフォルト:3600 sec(1時間) • 最小:900 sec(15分)、最大:43200 sec(12時間) 拒否のポリシーを追加することでセッションの無効化は可能 { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}} } } AWS Security Token Service API Reference (API Version 2011-06-15) AssumeRole https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters
  66. 66. 66 8.1の要件は高機能なIdPと連携することで ほぼ要件を満たせる?
  67. 67. 67 8.2: 認証強度の確保
  68. 68. 68 送信と保存中に認証情報を すべて読み取り不能とする
  69. 69. 69【参考】AWSのエンドポイントとSig v4 AWSサービスのエンドポイントは何れかのプロトコルをサ ポート • HTTP and HTTPS • HTTPS (Only) HTTP で送信される AWS リクエストに認証情報を追加 • シークレットアクセスキーを利用して署名のためのキーを生成 • アクセスキーを含むリクエストを署名 • APIでリクエストを検証
  70. 70. 70Signing Requests Authenticating Requests (AWS Signature Version 4) https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
  71. 71. 71Parameter StoreとSecret Manager 設定や認証情報の保存を想定したデータストア • KMSによる暗号化をサポート • Secret Managerは認証情報のローテーションをサポート • IAM Roleによる認証情報へのアクセス制御 詳細は後述・・・
  72. 72. 72 認証情報を変更する前にユーザの身元を確認
  73. 73. 73ルートアカウントのパスワードリセット 以下の手順で実行できる • マネージメントコンソールからパスワードのリセットを要求 • CAPTCHAのテキストを入力 • ルートアカウントのメールアドレスに再設定画面へのリンクが送付 される 紛失または忘れたルートユーザーのパスワードのリセット https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys_retrieve.html#reset-root-password
  74. 74. 74ルートアカウントのMFAリセット 以下の手順で実行できる • マネージメントコンソールからMFAのリセットを要求 • ルートアカウントのメールアドレスに再設定画面へのリンクが送付 される • アカウントに設定されている電話番号に応答し、コンソール上に表 示された番号を電話から入力 • MFAデバイスの再設定 これでもダメな場合はAWSサポートへ・・・ MFA デバイスの紛失および故障時の対応 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_lost-or-broken.html
  75. 75. 75
  76. 76. 76 パスワードポリシー (複雑さ、有効期限/ローテーション、再利 用の制限、初期パスワードの変更)
  77. 77. 77Password Policy パスワードの複雑さ、有効期限、再利用が制限される世代
  78. 78. 78アクセスキーのローテーション IAM Userは同時に2つまでアクセスキーを発行できる • 新しいアクセスキーを発行、アプリケーションに設定 • 古いアクセスキーが使われていないことを確認 • 使われていないことを確認し無効化(問題が発生したら有効化) • 古いアクセスの削除
  79. 79. 79Credential Reportによる認証情報の管理 パスワードやアクセスキーを最後にローテーションした日時を 確認できる • password_last_changed • access_key_1_last_rotated / access_key_2_last_rotated • Getting Credential Reports for Your AWS Account • https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting- report.html
  80. 80. 80Credential Report
  81. 81. 81初期パスワードの変更を強制 初回ログイン時にパスワードの変更を要求できる (初期パスワードの設定時に指定可能)
  82. 82. 82 8.3: 多要素認証の実装
  83. 83. 83所有物による認証 知識(パスワード)だけでは共有/漏洩のリスクが大きい 以下のMFAデバイスをサポート • Virtual MFA device • U2F security key • Hardware-based MFA device
  84. 84. 84マネージメントコンソールにおける多要素認証
  85. 85. 85AWS CLIにおける多要素認証 設定ファイル コマンド実行前にOTPの入力 • セッションの有効期限が切れる度に入力 [profile hogehoge] role_arn = arn:aws:iam::xxxxxxxxxxxx:role/nakayama source_profile = default mfa_serial = arn:aws:iam::yyyyyyyyyyyy:mfa/nakayama region = ap-northeast-1 $ aws sts get-caller-identity Enter MFA code for arn:aws:iam::yyyyyyyyyyyy:mfa/nakayama: (6桁の数字) 多要素認証を使用する https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-role.html#cli-configure-role-mfa
  86. 86. 86 8.7: データベースアクセスの制限
  87. 87. 87Parameter StoreとSecret Manager(再掲) 設定や認証情報の保存を想定したデータストア • KMSによる暗号化をサポート • Secret Managerは認証情報のローテーションをサポート • IAM Roleによる認証情報へのアクセス制御 • 管理者がParameter StoreやSecret Managerに接続情報を入力 • アプリケーションはIAM Roleの権限を利用して接続情報を取得
  88. 88. 88OSおよびRDBMSへのアクセス(再掲) EC2やRDSのインスタンス「内」に対するアクセス制御 • RDSに対してデータベースへ接続するための認証トークンの発行を 要求できる • データベース側で認証情報を管理する必要がない =アプリケーションに認証トークンを発行する権限があればよい(IAM Role 経由で付与) • RDS for MySQL / PostgreSQLでサポート • Systems Manager Session Managerを利用することで、パスワー ド/SSHキーなしにShellへのアクセスが可能
  89. 89. 89AWS CLIによる接続例 RDSHOST="rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com" TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )" mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/rds-combined-ca-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN コマンドライン: AWS CLI および mysql クライアントからの DB インスタンス への接続 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.html
  90. 90. 90 まとめ
  91. 91. 91まとめ 要件を実現するための機能はある 標準機能だけでは(体制の規模によっては)運用負荷が大きい 開発やサードパーティ製品による自動化/効率化も検討すると よさそう
  92. 92. 92

×