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

PCI DSSにおける認証認可インフラ編
クラスメソッド株式会社 AWS事業本部
2019/09/24
Nobuhiro Nakayama
1

2目次
PCI DSSにおける認証・認可の要件
AWSにおける認証・認可

3
PCI DSSにおける認証・認可の要件

5
要件 7: カード会員データへのアクセスを
業務上必要な範囲内に制限する（認可）

6
要件 8: システムコンポーネントへの
アクセスを識別・認証する

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

7.2 システムコンポーネントのアクセス制御システムを確立することで、ユーザの必要性に
基づいてアクセスを制限し、特に許可のない場合は「すべてを拒否」に設定する。アクセス
制御システムには以下の項目を含める必要がある。
• 7.2.1 すべてのシステムコンポーネントを対象に含む
• 7.2.2 職種と職務に基づく、個人への特権の付与
• 7.2.3 デフォルトでは「すべてを拒否」の設定

7.3 カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が文
書化されて使用されており、影響を受ける関係者全員に知られていることを、確実にする。
今日の勉強会のスコープ外

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分を超えた場合、ターミナルまたはセッションを再度アクティ
ブにするため、ユーザの再認証が必要となる。

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 初期パスワード/パスフレーズとリセットパスワード/パスフレーズをユーザごとに一意の値にリ
セットし、初回の使用後直ちに変更する。

8.3 CDE に対する、すべての非コンソール管理アクセス、ならびにすべてのリモートアク
セスについて、多要素認証を使用して安全に保護する。
• 8.3.1 CDE への管理者のアクセス権を持つ担当者によるすべての非コンソールアクセスに多要素認証
を組み込む。
• 8.3.2 事業体のネットワーク外からのすべてのリモートネットワークアクセス（ユーザと管理者の両方、
サポートやメンテナンスのための第三者のアクセスを含む）に多要素認証を組み込む。

8.4 以下を含む認証のポリシーと手順を文書化し、すべてのユーザに通達する。
• 強力な認証情報を選択するためのガイダンス
• ユーザが自分の認証情報を保護する方法についてのガイダンス
• 前に使用していたパスワードを再使用しないという指示
• パスワードが侵害された疑いがある場合にはパスワードを変更するという指示

8.5 次のように、グループ、共有、または汎用の ID やパスワード、または他の認証方法が
使用されていない。
• 汎用ユーザ ID が無効化または削除されている
• システム管理作業およびその他の重要な機能に対する共有ユーザ ID が存在しない
• システムコンポーネントの管理に共有および汎用ユーザ ID が使用されていない
• 8.5.1 サービスプロバイダのみの追加要件：
顧客環境へのリモートアクセス権を持つサービスプロバイダは（例：POS システムやサーバのサポー
トで）、各顧客に一意な認証情報（パスワード/パスフレーズなど）を使用する必要がある。

8.6 その他の認証メカニズムが使用されている（例えば、物理的または論理的セキュリティ
トークン、スマートカード、証明書など）これらのメカニズムの使用は、以下のように割り
当てる必要がある。
• 認証メカニズムは、個々のアカウントに割り当てなければならず、複数アカウントで共有するこ
とはできない
• 物理/論理制御により、意図されたアカウントのみがアクセスできるようにする必要がある

8.7 カード会員データを含むデータベースへのすべてのアクセス（アプリケーション、管理
者、およびその他のすべてのユーザによるアクセスを含む）が以下のように制限されている。
• データベースへのユーザアクセス、データベースのユーザクエリ、データベースに対するユーザ
アクションはすべて、プログラムによる方法によってのみ行われる。
• データベースへの直接アクセスまたはクエリはデータベース管理者のみに制限される。
• データベースアプリケーション用のアプリケーション ID を使用できるのはそのアプリケーショ
ンのみである（個々のユーザやその他の非アプリケーションプロセスは使用できない）。

8.8 識別と認証に関するセキュリティポリシーと操作手順が文書化されて使用されており、
影響を受ける関係者全員に知られていることを、確実にする。

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
サービスとしてのAWSが
どの程度要件を未対しているのか？

20
AWSにおける認証・認可

21
7.1: 権限を付与する対象の最小化

22
アクセスニーズの定義

23アクセスアドバイザーによる利用サービスの特定
サービスの最終アクセス時間データを表示

24CloudTrailによる証跡の保存
アカウントアクティビティをログに記録

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
最小限の特権に制限

27
職務定義のはなしなので割愛

28
個人の職種と職務に基づく
アクセス権の割り当て

29IAM Userに対するアクセス制御
権限付与の方法
• 【非推奨】IAM Userに権限を付与
• IAM Groupに権限を付与してIAM Userを参加させる
• IAM Roleに権限を付与してIAM Userを信頼
• Assume Roleで一時的な認証情報を取得できる
その他の制御方法
• Organizations SCPによるAWSアカウント横断のアクセス制御
• Permission BoundaryでIAM管理権限の「範囲」を制御

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承認アクションの例
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
7.2: 権限（ポリシー）の最小化

34
すべてのシステムコンポーネントが
制御の対象

35IAM Policyによるアクセス制御
Principal, Resource, Actionなどの要素で詳細な制御が可能
• PrincipalはIdentity-based policyでは利用できない（リソースポ
リシーなどで利用）
• Condition要素で、さらに細かい制御も可能
• 時刻、MFAの有無、接続元のIPアドレス、など

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

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

38OSおよびRDBMSへのアクセス
EC2やRDSのインスタンス「内」に対するアクセス制御
• RDSに対してデータベースへ接続するための認証トークンの発行を
要求できる
• データベース側で認証情報を管理する必要がない
• RDS for MySQL / PostgreSQLでサポート
• Systems Manager Session Managerを利用することで、パスワー
ド/SSHキーなしにShellへのアクセスが可能

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

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
（正しく）個人への特権の付与

42設計通りに構成されていることをテスト
事前評価
• CloudFormationやTerraformのコードレビュー
事後評価
• IAM Policy Simulator
• https://policysim.aws.amazon.com/
• awspec (OSS)
• https://github.com/k1LoW/awspec
• IAMの各種リソースをサポート

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
デフォルトでは「すべてを拒否」

45IAMの認可はDefault Deny
何も許可しなければ何もできない
Policy Evaluation Logic
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

46
8.1: 厳格な識別、不正な第三者の排除

47
すべてのユーザに一意のIDを割り当て

48所有物による認証
知識（パスワード）だけでは共有／漏洩のリスクが大きい
以下のMFAデバイスをサポート
• Virtual MFA device
• U2F security key
• Hardware-based MFA device

49IAM Roleが権限を委任する条件にMFAを追加

50
ユーザ ID、資格情報、およびその他の
識別オブジェクトの追加、削除、変更を管理

51AWS ConfigによるIAM Entityの構成管理

52AWS ConfigによるIAM Entityの構成管理
認証情報の発行
（グループへの追加に伴う）
権限の不要

53
契約終了したユーザのアクセスを
直ちに取り消す

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
90 日以内に非アクティブな
ユーザアカウントを削除/無効

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

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

59
「必要な期間内だけ有効」
「使用時に監視」

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
IAMユーザーに特権を一時的に付与する簡易承認ワークフローをSystems Manager (Automation) で実装してみた
https://dev.classmethod.jp/cloud/aws/workflow-to-add-temporary-privilege-by-ssm-automation/

62
ユーザ ID をロックアウト

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
セッションのアイドル状態が
15分を超えた場合、ユーザの再認証が必要

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
8.1の要件は高機能なIdPと連携することで
ほぼ要件を満たせる？

68
送信と保存中に認証情報を
すべて読み取り不能とする

69【参考】AWSのエンドポイントとSig v4
AWSサービスのエンドポイントは何れかのプロトコルをサ
ポート
• HTTP and HTTPS
• HTTPS (Only)
HTTP で送信される AWS リクエストに認証情報を追加
• シークレットアクセスキーを利用して署名のためのキーを生成
• アクセスキーを含むリクエストを署名
• APIでリクエストを検証

70Signing Requests
Authenticating Requests (AWS Signature Version 4)
https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

71Parameter StoreとSecret Manager
設定や認証情報の保存を想定したデータストア
• KMSによる暗号化をサポート
• Secret Managerは認証情報のローテーションをサポート
• IAM Roleによる認証情報へのアクセス制御
詳細は後述・・・

72
認証情報を変更する前にユーザの身元を確認

73ルートアカウントのパスワードリセット
以下の手順で実行できる
• マネージメントコンソールからパスワードのリセットを要求
• CAPTCHAのテキストを入力
• ルートアカウントのメールアドレスに再設定画面へのリンクが送付
される
紛失または忘れたルートユーザーのパスワードのリセット
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys_retrieve.html#reset-root-password

74ルートアカウントのMFAリセット
以下の手順で実行できる
• マネージメントコンソールからMFAのリセットを要求
• ルートアカウントのメールアドレスに再設定画面へのリンクが送付
される
• アカウントに設定されている電話番号に応答し、コンソール上に表
示された番号を電話から入力
• MFAデバイスの再設定
これでもダメな場合はAWSサポートへ・・・
MFA デバイスの紛失および故障時の対応
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_lost-or-broken.html

76
パスワードポリシー
（複雑さ、有効期限／ローテーション、再利
用の制限、初期パスワードの変更）

77Password Policy
パスワードの複雑さ、有効期限、再利用が制限される世代

78アクセスキーのローテーション
IAM Userは同時に2つまでアクセスキーを発行できる
• 新しいアクセスキーを発行、アプリケーションに設定
• 古いアクセスキーが使われていないことを確認
• 使われていないことを確認し無効化（問題が発生したら有効化）
• 古いアクセスの削除

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

81初期パスワードの変更を強制
初回ログイン時にパスワードの変更を要求できる
（初期パスワードの設定時に指定可能）

82
8.3: 多要素認証の実装

83所有物による認証
知識（パスワード）だけでは共有／漏洩のリスクが大きい
以下のMFAデバイスをサポート
• Virtual MFA device
• U2F security key
• Hardware-based MFA device

84マネージメントコンソールにおける多要素認証

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
8.7: データベースアクセスの制限

87Parameter StoreとSecret Manager（再掲）
設定や認証情報の保存を想定したデータストア
• KMSによる暗号化をサポート
• Secret Managerは認証情報のローテーションをサポート
• IAM Roleによる認証情報へのアクセス制御
• 管理者がParameter StoreやSecret Managerに接続情報を入力
• アプリケーションはIAM Roleの権限を利用して接続情報を取得

88OSおよびRDBMSへのアクセス（再掲）
EC2やRDSのインスタンス「内」に対するアクセス制御
• RDSに対してデータベースへ接続するための認証トークンの発行を
要求できる
• データベース側で認証情報を管理する必要がない
＝アプリケーションに認証トークンを発行する権限があればよい（IAM Role
経由で付与）
• RDS for MySQL / PostgreSQLでサポート
• Systems Manager Session Managerを利用することで、パスワー
ド/SSHキーなしにShellへのアクセスが可能

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

91まとめ
要件を実現するための機能はある
標準機能だけでは（体制の規模によっては）運用負荷が大きい
開発やサードパーティ製品による自動化／効率化も検討すると
よさそう

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

Similar to PCI DSSにおける認証認可インフラ編 (20)

More from Nobuhiro Nakayama

More from Nobuhiro Nakayama (20)