Download as PDF, PPTX
![29アクセスコントロールの義務化を自動化する
例：IAM Tagによるアクセス制御
IAM プリンシパルへのアクセスの制御
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_iam-tags.html#access_iam-tags_control-principals
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"ec2:startInstances",
"ec2:stopInstances"
],
"Resource": "*",
"Condition": {"StringEquals":
{"ec2:ResourceTag/costcenter": "${aws:PrincipalTag/cost-center}"}}
}
}](https://image.slidesharecdn.com/wasecurity20200129nakayama-200129095030/75/AWS-AWS-Well-Architected-Tool-29-2048.jpg)
More Related Content
![[AWSマイスターシリーズ]Identity and Access Management (IAM)](https://cdn.slidesharecdn.com/ss_thumbnails/20130716aws-meister-regenerate-iam-public-130728224341-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to AWSのセキュリティを考える！「AWS Well-Architected Tool」活用術セミナー セキュリティの柱を解説
![[JAWS Days 2020] AWS Well-Architected フレームワークのご紹介](https://cdn.slidesharecdn.com/ss_thumbnails/202003-jaws-daywellarchitectedframework-200325072902-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight](https://cdn.slidesharecdn.com/ss_thumbnails/ctond2019morningsessionsecurity-191027185908-thumbnail.jpg?width=640&height=640&fit=bounds)
AWSのセキュリティを考える！「AWS Well-Architected Tool」活用術セミナー セキュリティの柱を解説
- 1.
- 2.
- 3. 3本セッションについて • セキュリティに関する原理・原則に関する話が多いです • 一見すると、当たり前のこと・基本的なことが多いです •抽象度が少し高いかもしれません • 併せて原理・原則に則った具体策を紹介します • re:Invent 2019で発表された新サービスなど、最新の情報も紹介します
- 4. 4Agenda • Well-Architected Framework •設計原則 • ベストプラクティス • まとめ
- 5.
- 6. 6Well-Architected Frameworkとは？ システム設計および運用に関する考え方・ベストプラクティス • AWSのソリューションアーキテクトとユーザーの経験に基づく •5つの柱でシステムを捉える （セキュリティ、信頼性、運用性、パフォーマンス、コスト） • それぞれの柱の考え方に基づいて評価対象のシステムをレビュー（質問形式） • 詳細はホワイトペーパーを参照 • https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf
- 7. 7Well-Architected Frameworkとは？ レビューの進め方 • CTO、アーキテクト、開発者、運用チームメンバーなど可能な限り全ての関係 者が参加してもらう •必要に応じてソリューションアーキテクトがレビューをサポート （慣れたらWell-Architected ToolでのセルフチェックもOK） • W-Aに基づくレビューは監査ではない （現状を踏まえて今後どうするかを考える機会） • ビジネス要件を踏まえて改善の優先度を設定 （何を優先するかユーザーが決める必要がある / 全てのベストプラクティスに 準拠する必要はない） • プロジェクトの早い段階で実施することを推奨 （問題の発生を予防 / もちろんリリース後のアセスメントにも利用可能）
- 8.
- 9. 9（セキュリティに関する）設計原則 • Implement astrong identity foundation（強固な認証基盤） • Enable traceability（トレーサビリティの担保） • Apply security at all layers（全てのレイヤーの保護） • Automate security best practices（自動化） • Protect data in transit and at rest（保存・転送時のデータ保護） • Keep people away from data（人からデータを遠ざける） • Prepare for security events（セキュリティイベントに備える）
- 10. 10強固な認証基盤 認証要素 • 知識、所有、生体の組み合わせ（パスワード認証は「知識」） IDのライフサイクル管理 • 異動や退職などのイベントに合わせた権限の変更やIDの失効など 認容要素の強度 •パスワードの複雑さ、複製のしにくさ、など 最小権限 • 職務定義とそれに必要な権限
- 11.
- 12. 12全てのレイヤーの保護 Attack Surface • 人、ファシリティ、ネットワーク、OS、ミドルウェア、アプリケーショ ン・・・ •攻撃者はどこか一つの穴を足がかりに目的を達成しようとする 多層防御 • 恒久的に完全な対策は存在しない • 複数の対策を組み合わせる必要がある
- 13. 13自動化 セキュリティリスクを抑制 • 設計通りに設定されていないリスクを排除（設定を自動化） • 設計・設定自体が適切でないリスクを排除（評価/ 是正の自動化） セキュリティイベントへの対応 • 大規模化・高度化する攻撃を一組織だけで対応することは一般的に困難 • 人がボトルネックにならない対策が必要
- 14. 14保存・転送時のデータ保護 データの分類 • 組織には多様なデータが存在 • 機密性の高いデータに対する要件に合わせるのは効率が悪い データの保護 •データの重要度に応じて、暗号化 / アクセス制御（権限管理） / トークン化な どの保護を実施
- 15. 15人からデータを遠ざける データを人が直接扱うリスク • 誤った変更や削除 /改竄 • クレデンシャルの漏洩 / 搾取からの情報漏洩 ツールを介したデータ利用 • データに対する操作を規定 / 制限することでリスクを緩和
- 16. 16セキュリティイベントに備える もしセキュリティイベントが起こったら・・・ • イベントの検知／外部からの通報 • 現状調査 •責任者へのエスカレーション • 問題の緩和（認証情報の無効化 / 侵害されたリソースの隔離 / サービス停止な ど） • 利用者など利害関係者への報告・広報 • サービスの原状回復、暫定対応 • 根本原因調査および対策 • 被害の補償 • 他・・・
- 17.
- 18.
- 19. 19ベストプラクティス • Identity andAccess Management（認証・認可） • Detective Controls（発見的統制） • Infrastructure Protection（インフラストラクチャの保護） • Data Protection（データの保護） • Incident Response（インシデントレスポンス）
- 20. 20ベストプラクティス • Identity andAccess Management（認証・認可） • Detective Controls（発見的統制） • Infrastructure Protection（インフラストラクチャの保護） • Data Protection（データの保護） • Incident Response（インシデントレスポンス）
- 21. 21認証・認可 SEC 1. 認証情報と認証をどのように管理していますか? SEC2. 人為的なアクセスをどのように制御していますか? SEC 3. プログラムによるアクセスをどのように制御していますか?
- 22. 22認証情報と認証をどのように管理していますか? アイデンティティおよびアクセス管理要件を定義する AWSルートユーザーを保護する Multi-Factor Authentication (MFA) の使用を義務化する アクセスコントロールの義務化を自動化する 一元化されたフェデレーションプロバイダーと統合する パスワード要件を義務化する 認証情報を定期的にローテーションする 認証情報を定期的に監査する
- 23. 23アイデンティティおよびアクセス管理要件を定義する 例：クレジットカードを扱うシステムの場合 • 平成30年６月１日に改正割賦販売法が施行 • 販売店におけるセキュリティ対策の実施が義務化 •PCI DSSへの準拠 or カード情報の非保持化 例：PCI DSSにおけるアイデンティティおよびアクセス管理要件 • 要件7：カード会員データへのアクセスを、業務上必要な範囲内に制限する • 要件8：システムコンポーネントへのアクセスを識別・認証する • 【資料公開】PCI DSSの認証認可に関する要件とそのための実装を学ぶ勉強会 をやりました（インフラ編） • https://dev.classmethod.jp/cloud/aws/pci-dss-auth-by-iam/
- 24. 24AWS ルートユーザーを保護する AWSのルートユーザー • AWSアカウント作成時に存在する唯一のユーザー •全ての権限を持つ • IAMでは権限を制御できないが、OrganizationsのSCPで制御できる ベストプラクティス • アクセスキーを利用しない • MFAを有効化する • 普段は利用しない • ルートユーザーの利用はCloudTrailのログから検知できる • ルートユーザーでしかできないことがある • https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html
- 25. 25Multi-Factor Authentication (MFA)の使用を義務化する 認証要素を追加 • デフォルトはパスワードによる認証（知識 / Something you know） • 所有物による認証を追加できる（Something you have） • TOTP(RFC6238)およびU2Fをサポート MFAの強制 • 認可する条件としてMFAによる認証を経ているか評価できる • 例：MFAを利用していない場合、認証情報の自己管理以外のアクションを禁止 • 例：MFAを利用している場合、IAM Roleに対する一時認証情報の取得を許可（IAM Roleにつ いては後述）
- 26. 26Multi-Factor Authentication (MFA)の使用を義務化する 例：IAM Roleに設定する信頼ポリシー { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } } } Creating a Role to Delegate Permissions to an IAM User より抜粋 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html
- 27. 27アクセスコントロールの義務化を自動化する アクセス制御を自動化する手段 • Service ControlPolicy (AWS Organizations) • Organizationsで集中管理されたAWSアカウントをグループ化、行使できる権限を制御 • IAM Tagによるアクセス制御 • Principal（IAM UserやIAM Role）に付与したタグに基づいたアクセス制御 • CloudFormation StackSet / ControlTower • 複数のアカウント・リージョンにAWSリソースをプロビジョニング可能 • 例：IAM Role / Config / GuardDuty などを一括でプロビジョニング / 有効化
- 28.
- 29. 29アクセスコントロールの義務化を自動化する 例：IAM Tagによるアクセス制御 IAM プリンシパルへのアクセスの制御 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_iam-tags.html#access_iam-tags_control-principals { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "ec2:startInstances", "ec2:stopInstances" ], "Resource": "*", "Condition": {"StringEquals": {"ec2:ResourceTag/costcenter": "${aws:PrincipalTag/cost-center}"}} } }
- 30. 30一元化されたフェデレーションプロバイダーと統合する なぜ認証を統合するのか • 管理する認証情報を減らすことで利用者の利便性向上とリスクの緩和 認証の統合 • AWSSingle Sign-on • SAML / OIDC をサポートするIdP • ActiveDirectory(ADFS) / Ping Identity など • OneLogin / Okta / Azure AD など
- 31. 31パスワード要件を義務化する IAM Userに対するパスワードポリシーの適用 • パスワードの最小長 •少なくとも 1 つの大文字が必要 • 少なくとも 1 つの小文字が必要 • 少なくとも 1 つの数字が必要 • 少なくとも 1 つのアルファベット以外の文字が必要 • ユーザーにパスワードの変更を許可 • パスワードの失効を許可（有効期限） • パスワードの再利用を禁止 • パスワードの有効期限で管理者のリセットが必要
- 32. 32認証情報を定期的にローテーションする 静的な認証情報 • アクセスキー（有効期限なし） • IAMUserのパスワード（パスワードポリシーで有効期限を強制可能） アクセスキーのローテーション • IAM Userに対してアクセスキーを2つ発行できる • 入れ替え後、古いアクセスキーが利用されていないことを確認してから無効化 / 削除できる
- 33. 33認証情報を定期的に監査する 認証情報レポートの取得 • 最終ログイン日やアクセスキーの作成日時などを出力可能 • IAMのコンソールから取得可能 •レポートのフォーマットはドキュメントを参照 • https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_getting- report.html#id_credentials_understanding_the_report_format
- 34. 34人為的なアクセスをどのように制御していますか? 人為的なアクセス要件を定義する 最小限の権限を付与する 各個人に一意の認証情報を割り当てる ユーザーライフサイクルに基づいて認証情報を管理する 認証情報管理を自動化する ロールまたはフェデレーションを通じてアクセス権を付与する
- 35. 35人為的なアクセス要件を定義する 権限設計のための職務定義 • 登場人物を整理し、職務を遂行するために必要な権限 /与えてはいけない権限 を整理 •ネットワーク管理 / サーバー管理 / アプリ開発 / 監査・セキュリティ / AWSアカウント管理 / 請求管理 など • 「どのリソース」(Resource)に対して「何の操作」(Action)をする必要があるのか？ • ネットワーク管理者であれば、組織内のネットワークを維持するためにネットワークアドレス やルーティングを統制する責務を負う （オンプレミスとAWSを接続するような用途の場合にはVPC / Subnet / RouteTable / IGW / VGW / VPN / DirectConnect の管理権限が必要） • CloudTrail（AWSリソースに対する操作ログを取得するサービス）の管理操作は限られた管理 者意外には禁止するべき
- 36. 36最小限の権限を付与する 最小権限を付与することが原則 • ビジネス環境 /AWSのアップデートと共に最小権限は変化しうる • それに伴うアーキテクチャー / 運用業務の変化により、最小権限も変化 最小権限を見直すための手段 • Access Advisor • サービスに対して最後にアクセスした日時を確認できる • IAM Access Analyzer / S3 Access Analyzer • 信頼ゾーン外（AWSアカウント外）からのアクセス許可を検出・管理できる • 各種リソースポリシーをサポート（S3、KMS、IAM Role、SQS、Lambda）
- 37. 37各個人に一意の認証情報を割り当てる なぜ一意の認証情報を割り当てる必要があるのか • 監査可能性を担保できない • ユーザーを共有した場合、CloudTrailでアクティビティを記録しても実際に「だれが」アクセ スしたか確認できない（「否認」が可能になる） •MFA（複製が困難な所有物による認証）を「強制」することで認証情報の共有 は防止できる • IAM Policy / Trust Policy(IAM Role)でMFAの利用を強制できる（前述）
- 38. 38ユーザーライフサイクルに基づいて認証情報を管理する ユーザーライフサイクルイベント • 組織への入社 /異動 / 退職 • プロジェクトへの参画 / ロールチェンジ / 離脱 • 他・・・ • 定期的な棚卸しも重要
- 39. 39認証情報管理を自動化する 認証情報の管理業務 • 認証情報レポートでユーザーの最終ログイン日などを確認できる（前述） • 確認結果に基づいてログインしていないユーザーの削除などを実施 •これらを人力で行うことは負担 / 作業自体を失念するリスク 自動化の実現例 • 例：Automated IAM User Cleanup • https://github.com/awslabs/aws-well-architected- labs/tree/master/Security/200_Automated_IAM_User_Cleanup • 長期間利用されていないユーザー / 認証情報（パスワード・アクセスキー）を自動で削除 / 無 効化 / レポートしてくれる • （レポートを受信したらちゃんとアクションしましょう）
- 40.
- 41.
- 42. 42ロールまたはフェデレーションを通じてアクセス権を付与する IAM Role • 事前に信頼しているプリンシパル（他のAWSアカウントやIdP）に対して権限 を委譲するための仕組み •権限委譲先に対して一時的な認証情報を発行できる • 必要に応じて一時的な認証情報を発行して利用することで、認証情報が漏洩するリスク / 漏洩 した場合の影響を緩和できる • マネージメントコンソールでスイッチロールするときや、EC2インスタンスにインスタンスメ タデータ経由で認証情報を提供する際に必要
- 43. 43プログラムによるアクセスをどのように制御していますか？ プログラムによるアクセス要件を定義する （最小限の権限を付与する） （認証情報管理を自動化する） 各コンポーネントに一意の認証情報を割り当てる （ロールまたはフェデレーションを通じてアクセス権を付与する） 動的認証を実装する
- 44. 44プログラムによるアクセス要件を定義する 権限設計のための要件定義 • 登場人物を整理し、職務を遂行するために必要な権限 /与えてはいけない権限 を整理 •AWSリソース / システム利用者 / 外部サービス など • 「どのリソース」(Resource)に対して「何の操作」(Action)をする必要があるのか？ • 例：非同期で処理するジョブを受け付けるサーバー • 特定のQueueに対するMessage Queue (SQS) へのメッセージ送信権限 • 特定のS3 Bucket / CloudWatch Logs (Log Group) へのファイル書き込み権限（アプリケー ションログの保存） • 他・・・
- 45.
- 46. 46動的認証を実装する 一時認証情報の再取得 • IAM Roleを介して取得した認証情報には有効期限がある •有効期限が切れた場合、認証情報を再取得する必要がある • AWS SDK / CLIを利用する場合、自動で認証情報を再取得できる • EC2インスタンス上で利用する場合、インスタンスメタデータから認証情報を取得できる IMDSv2 (Instance Metadata Service) • SSRFを利用した認証情報の窃取リスクを緩和する方式を提供 （事前にTokenを取得して認証情報をリクエストする必要がある） • EC2インスタンスでv1の無効化 / 併用 / v2の強制が可能 • メタデータサービス自体の無効化も可能
- 47. 47動的認証を実装する Instance Metadata (v1) $curl http://169.254.169.254/latest/meta-data/iam/security-credentials/(Profile name) { "Code" : "Success", "LastUpdated" : "2019-09-02T07:33:18Z", "Type" : "AWS-HMAC", "AccessKeyId" : "XXXXXXXXXXXXXXXXXXXX", "SecretAccessKey" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", "Token" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", "Expiration" : "2019-09-02T14:07:29Z" }
- 48. 48ベストプラクティス • Identity andAccess Management（認証・認可） • Detective Controls（発見的統制） • Infrastructure Protection（インフラストラクチャの保護） • Data Protection（データの保護） • Incident Response（インシデントレスポンス）
- 49. 49発見的統制 SEC 4. セキュリティイベントをどのように検出し、調査していますか？ SEC5. 新しいセキュリティ脅威に対してどのように防御していますか?
- 50. 50セキュリティイベントをどのように検出し、調査していますか？ ログの要件を定義する メトリクスの要件を定義する アラートの要件を定義する サービスとアプリケーションのログ記録を設定する ログを一元的に分析する 主要な指標に関するアラートを自動化する 調査プロセスを開発する
- 51. 51ログの要件を定義する 例：PCI DSSにおけるログの要件（の一部） • 10.2次のイベントを再現するために、すべてのシステムコンポーネントの自動 監査証跡を実装する。 • 10.2.1 カード会員データへのすべての個人アクセス • 10.2.2 ルート権限または管理権限を持つ個人によって行われたすべてのアクション • 10.2.3 すべての監査証跡へのアクセス • 10.2.4 無効な論理アクセス試行 • 10.2.5 識別と認証メカニズムの使用および変更、およびルートまたは管理者権限をもつアカウ ントの変更、追加、削除のすべて • 10.2.6 監査ログの初期化、停止、一時停止 • 10.2.7 システムレベルオブジェクトの作成および削除 • 悪意のある行為を識別・追跡するための情報
- 52. 52メトリクスの要件を定義する リスクのあるアクティビティの例 • 認証の失敗 • MFAを利用してない認証 •普段アクセスされないホストからの管理アクセス(SSH / RDP) • 特定 / 不特定多数のホストからの大量アクセス
- 53. 53アラートの要件を定義する システム管理者にアクションを促すためのアラート • レスポンスが必要なイベント（インシデント）を想定 • レスポンスが不要であればアラートは不要 •セキュリティインシデントとレスポンスの例 • 認証情報を誤って公開 → 認証情報の無効化 • 特定ホストからの大量アクセス → 特定ホスト（IPアドレス）からのアクセスをブロック • 有害なドメイン・ホストの名前解決 → リソースの隔離 • アラートの受信者の決定 • インシデントの影響を受けるリソースの管理者 など • レスポンスをするために必要な権限の付与を併せて実施
- 54. 54サービスとアプリケーションのログ記録を設定する AWS上で取得するべきログ • AWSサービスのログ・イベント • WAF/ CloudFront / ELB / S3 / RDS(Audit) / VPC FlowLogs / CloudTrail / Config / GuardDuty / Access Analyzer / Personal Health Dashboard etc • アプリケーション / ミドルウェア / OSのログ • 目的を定義（トラブルシュート、統計、性能分析 など） • 目的を意識したログの出力（ログレベル / コンテキスト – ユーザーIDやリクエストID / 英語 / JSON など） ログの保存先 • S3 / CloudWatch Logs / 3rd-Party (sumo logic etc) • 後述する分析を想定して保存先を選択
- 55. 55ログを一元的に分析する ログの分析手段 • Athena • CloudWatchLogs Insight • 3rd-Party (sumo logic / Elasticsearchなど)
- 56.
- 57. 57主要な指標に関するアラートを自動化する セキュリティイベントの検出 • GuardDuty • 事前定義済の脅威を検出し、EventBridge / SNS などで通知できる • CloudWatch Logs • メトリクスフィルタを利用して特定条件を満たすログの出力数をカスタムメトリクスとして投 稿、通知
- 58. 58主要な指標に関するアラートを自動化する UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration • Credentials thatwere created exclusively for an EC2 instance through an instance launch role are being used from an external IP address. （インスタンス起動ロールを通じて EC2 インスタンス専用に作成された認証 情報が外部 IP アドレスから使用されています。）
- 59.
- 60. 60主要な指標に関するアラートを自動化する AWSマネージメントコンソールへのログイン失敗 • CloudTrailでマネージメントコンソールの認証エラーを記録 • CloudWatchLogsのメトリクスフィルターで認証エラーの頻度を計測 • https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudwatch-alarms-for- cloudtrail.html#cloudwatch-alarms-for-cloudtrail-signin • CloudWatch Alarmで通知 { ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }
- 61. 61調査プロセスを開発する 調査ツールの提供開始 • CloudTrail Insights •通常より頻度の高いAPIコール（変更）を検出、イベントの詳細確認 • Amazon Detective • CloudTrail / VPC FlowLogs / GuardDutyをソースとする調査分析ツール 必要に応じて外部リソース（専門の調査会社など）の利用を検討 • フォレンジックなどには専門の知識 / 技能 / 経験が必要
- 62.
- 63.
- 64. 64新しいセキュリティ脅威に対してどのように防御していますか? 組織要件、法的要件、コンプライアンス要件に関する最新情報を入手する セキュリティのベストプラクティスに関する最新情報を入手する セキュリティ脅威に関する最新情報を入手する 新しいセキュリティサービスとセキュリティ機能を定期的に評価する 脅威モデルを使用してリスクを定義し優先順位付けする 新しいセキュリティサービスとセキュリティ機能を実装する
- 65. 65組織要件、法的要件、コンプライアンス要件に関する最新情報を入手する 例：PCI DSS 4.0のリリース準備中 •主要な変更点 • Authentication, specifically consideration for the NIST MFA/password guidance （パスワード要件） • Broader applicability for encrypting cardholder data on trusted networks （信頼できるネットワーク内での通信暗号化） • Monitoring requirements to consider technology advancement （監視） • Greater frequency of testing of critical controls; for example, incorporating some requirements from the Designated Entities Supplemental Validation (PCI DSS Appendix A3) into regular PCI DSS requirements. （補足要件を通常要件へ移行）
- 66. 66セキュリティのベストプラクティスに関する最新情報を入手する 新しい脅威・環境に対応するベストプラクティス • 例：NIST SP800-63B • パスワードの定期変更がリスクの緩和策として有効ではない （定期変更を強制されるとユーザーは弱いパスワードを利用しがち） • ただし、パスワードの設定時に脆弱なパスワードをはじくことも等も求められている • 都合のいいところだけを切り取らず、原典の確認をするべき • 例：ゼロトラストセキュリティ • 境界での防御の限界 • 内部ネットワークを信頼しない • 全てのデバイス / ユーザー / アプリケーションを認証および評価
- 67. 67セキュリティ脅威に関する最新情報を入手する 脆弱性情報の収集 • 例：Security Bulletins •https://aws.amazon.com/security/security-bulletins/ • 例：CVE • https://cve.mitre.org/ 実際のセキュリティインシデント • 例：piyolog • https://piyolog.hatenadiary.jp/ • 報道されたセキュリティインシデントに関する情報がまとめられている
- 68. 68新しいセキュリティサービスとセキュリティ機能を定期的に評価する ここまでで紹介したAWSの新サービス / 新機能 •IAM Access Analyzer / S3 Access Analyzer • Amazon Detective (preview) • CloudTrail Insights • Instance Metadata Service v2
- 69.
- 70. 70脅威モデルを使用してリスクを定義し優先順位付けする 脅威モデル • 「脅威モデリングは、開発対象のソフトウェアがどのようなセキュリティ脅威 にさらされており、攻略される可能性を持ちうるかを洗い出す活動である。」 • https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c101.html •例：STRIDE • Spoofing（なりすまし） • Tampering（改竄） • Repudiation（否認） • Information disclosure (privacy breach or data leak)（情報漏洩） • Denial of service（サービス妨害） • Elevation of privilege（特権昇格）
- 71. 71新しいセキュリティサービスとセキュリティ機能を実装する 以下のサービスを本番環境で利用していますか？ • Access Analyzer •信頼ゾーン外からのアクセス許可が検出された時の運用フローの確立 • Amazon Detective(Preview) • CloudTrail Insights • 異常検知時の運用フローの確立 • Instance Metadata Service v2 • AWS SDK / CLIなどコンポーネントの更新 • EC2インスタンス作成フロー / ポリシーの検討（v2のみを利用 / 強制 等）
- 72. 72ベストプラクティス • Identity andAccess Management（認証・認可） • Detective Controls（発見的統制） • Infrastructure Protection（インフラストラクチャの保護） • Data Protection（データの保護） • Incident Response（インシデントレスポンス）
- 73. 73インフラストラクチャの保護 SEC 6. ネットワークをどのように保護していますか? SEC7. コンピューティングリソースをどのように保護していますか?
- 74. 74ネットワークをどのように保護していますか? ネットワーク保護要件を定義する 露出を制限する 設定管理を自動化する ネットワーク保護を自動化する 検査および保護を実装する すべてのレイヤーでトラフィックをコントロールする
- 75. 75ネットワーク保護要件を定義する 例：PCI DSSにおけるネットワーク保護要件（の一部） • 要件1カード会員データを保護するために、ファイアウォールをインストール して構成を維持する • 1.2 信頼できないネットワークとカード会員データ環境内のすべてのシステムコンポーネント の接続を制限する、ファイアウォール構成を構築する。 • 1.3 インターネットとカード会員データ環境内のすべてのシステムコンポーネント間の、直接 的なパブリックアクセスを禁止する。（DMZを介した必要最小限のアクセス以外は禁止）
- 76. 76露出を制限する VPCによるアクセス制御 • Security Group/ NACLによるアクセス制御 • Security Groupはインスタンスやエンドポイントに適用可能 / ステートフル • NACLはSubnetに適用可能 / ステートレス • Subnet / Route Tableによるアクセス制御 • Subnetに割り当てるRouteTableでSubnet上のインスタンスがアクセスできる範囲を制御 • Internet Gatewayへのルート（リソースをインターネットへ着信可能） • NAT Gateway（リソースからインターネットへの発信可能） • VPC Endpoint（AWSサービスへの発信可能） • VPC内のみ（VPC内のみアクセス可能）
- 77. 77設定管理を自動化する 設定の自動化ツール • CloudFormation /CDK / Terraform など • 設定をコード化 • 設定作業のミスは防止できるが、設計自体を間違っていれば別のリスクが発生 設計の評価 • 例：cfn-nag https://github.com/stelligent/cfn_nag • プロビジョニング前にCloudFormationテンプレートのセキュリティリスクを評価 （S3バケットが公開されているか など） • 例：Config Rule (Conformance Pack) / 3rd-Party (Dome9 / RedLock など) • プロジビョニング済のAWSリソースの設定を評価 • IAM Best-PracticeやPCI DSS等のコンプライアンス要件を満たしているかを評価
- 78. 78突然ですが宣伝です Dome9のハンズオンをやります • https://dev.classmethod.jp/news/200213_dome9/ • 私が講師をやります •ハンズオンで触れる主な機能 • AWSリソースの設定評価 • ネットワークアクセス制御設定の可視化と管理 • 特権管理
- 79. 79ネットワーク保護を自動化する 例：AWS WAFの運用自動化 • AWSWAF セキュリティオートメーション • https://aws.amazon.com/jp/solutions/aws-waf-security-automations/ • 3rd-Party • WafCharm など
- 80. 80検査および保護を実装する WAFによるWebアプリケーションの保護 • AWS WAFManaged Rule • 3rd-Partyによるルールの提供 • Shield Advanced • DDoSの可視化および緩和、DRT(DDoS Response Team)によるAWS WAFの設定支援 IPS / IDSによるプラットフォームの保護 • 3rd-Party IPS/IDS • AWSとしてIPS/IDSは提供していない（3rd-Party製品を利用する必要がある） • 例：Trend Micro DeepSecurity（ホスト型）
- 81. 81すべてのレイヤーでトラフィックをコントロールする 多層防御が重要 • アプリケーション • WAF •Shield Advanced • プラットフォーム（OS・ミドルウェア） • IPS / IDS • マルウェア対策 • ネットワーク • Security Group / NACL • Subnet / Route Table
- 82. 82コンピューティングリソースをどのように保護していますか? コンピューティング保護要件を定義する 脆弱性をスキャンし、パッチを適用する 設定管理を自動化する コンピューティング保護を自動化する 攻撃領域を削減する マネージドサービスを活用する
- 83. 83コンピューティング保護要件を定義する 例：PCI DSSにおけるコンピューティングリソース保護要件（の一部） • 要件5: すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェ アまたはプログラムを定期的に更新する • 要件 6: 安全性の高いシステムとアプリケーションを開発し、保守する • 6.1 セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、 新たに発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を 割り当てるプロセスを確立する。
- 84. 84脆弱性をスキャンし、パッチを適用する 脆弱性のスキャンおよび適用 • Systems Managerによる脆弱性スキャンと適用が可能 •タグなどで管理対象を一括指定 • パッチ適用時の再起動を制御 • 必要に応じて運用性しやすい3rd-Partyサービスを利用 • 例：FutureVuls • 脆弱性のトリアージ（攻撃コードの有無、等によるフィルタリング） • Systems Manager Run Commandによる適用（パッチ適用のためのコマンドを生成） • IPS / IDS連携（仮想パッチの適用状況を確認可能）
- 85. 85設定管理を自動化する 設定情報の集中管理 • Parameter Store •設定情報や認証情報を保存 • IAM Role(Instance Profile)によるアクセス制御 設定情報の段階的なデプロイ • AppConfig • 設定のみを素早くデプロイしたいユースケースに対応するための機能 • 段階的なデプロイ • 問題が発生したときにはロールバックが可能 • アプリケーションは定期的にAppConfigで設定がデプロイされていないかポーリングする必要 がある
- 86. 86コンピューティング保護を自動化する コンピューティングリソースの保護の例 • EC2 • IPS/ IDSで仮想パッチの自動適用 • マルウェア対策で定義ファイルの自動更新 • Container • ECRでコンテナイメージのスキャンが可能 • https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html • Lambda • 利用するライブラリ等が脆弱でないか評価（デプロイパッケージやレイヤーの管理責任はユー ザーにある）
- 87. 87攻撃領域を削減する サービスによる管理責任範囲の違い • EC2 • OS/ ミドルウェア / アプリケーション / 権限をユーザーが管理 • Lambda • デプロイパッケージとレイヤー / アプリケーション / 権限をユーザーが管理 • OS / ミドルウェア（ランタイム）の管理はAWSの責任 セキュリティを強化したAMI • OSレイヤーのセキュリティ強化をサポート • 例：STIGs (Security Technical Implementation Guides) • https://dev.classmethod.jp/cloud/aws/windows-ami-stigs/
- 88. 88マネージドサービスを活用する マネージドサービスによる運用タスクのオフロード • 例：RDS • メンテナンスウィンドウでのセキュリティパッチの自動適用 •バックアップウィンドウでのスナップショットの自動取得 • 監査ログの収集 • ボリュームの暗号化とキーのローテーション • IAMを利用したアクセス許可（動的な認証情報の取得）
- 89. 89ベストプラクティス • Identity andAccess Management（認証・認可） • Detective Controls（発見的統制） • Infrastructure Protection（インフラストラクチャの保護） • Data Protection（データの保護） • Incident Response（インシデントレスポンス）
- 90. 90データの保護 SEC 8. データをどのように分類していますか? SEC9. 保管中のデータをどのように保護していますか? SEC 10. 伝送中のデータをどのように保護していますか?
- 91. 91データをどのように分類していますか? データ分類要件を定義する データ保護コントロールを定義する データの識別を実行する 識別および分類を実装する データのタイプを特定する
- 92. 92データ分類要件を定義する 例：PCI DSSにおけるカード会員データと機密認証データの定義 • カード会員データ •プライマリアカウント番号 (PAN) • カード会員名 • 有効期限 • サービスコード • 機密情報データ • フルトラックデータ • CAV2/CVC2/CVV2/CID • PINまたはPINブロック
- 93. 93データ保護コントロールを定義する 例：PCI DSSでアカウントデータをどのように扱うべきか • プライマリアカウント番号(PAN) • 要件3.4に基づいて読み取り不能にする • ワンウェイハッシュ / トランケート / トークナイゼージョン / 強力な暗号化 • 機密情報データ • 要件3.2に基づき保存不可 通常のデータ保護に加えて、より強力な制御を実施
- 94. 94データの識別を実行する 保護対象のデータを識別する方法の一例 • S3で管理する場合 • 書き込み時にオブジェクトに対してタグを付与 •RDSで管理する場合 • インスタンスに管理対象のデータが保存されていることを示すタグを付与 • PCI DSSにおいては、カード会員データがどこを流れるかを示す図の作成と管理（最新化）が 要求されている • 「1.1.3 システムとネットワーク内でのカード会員データのフローを示す最新図」
- 95. 95識別および分類を実装する Amazon Macieによるデータ管理 • データの検出と分類（S3をサポート） •データのアクティビティを監視 / 不審なアクティビティ発生時にアラート • データの可視化（分類、アクティビティ） 分類手法 • コンテンツタイプ / ファイル拡張子 / テーマ / 正規表現 / 個人情報(PII) / SVMベースの分類 • 「Amazon Macie でデータを分類する」 • https://docs.aws.amazon.com/ja_jp/macie/latest/userguide/macie-classify-data.html
- 96.
- 97. 97データのタイプを特定する 例：PCI DSSの場合 • プライマリアカウント番号(PAN) を適切に取り扱う必要がある • 要件3.4への準拠が求められる • PANを読み取り不可の状態にして保存する方法 • ワンウェイハッシュ • トランケート • トークナイゼージョン • 強力な暗号化 • 非保持化も有効な対策（リスクの転嫁）
- 98. 98保管中のデータをどのように保護していますか? 保管中のデータの管理と保護に関する要件を定義する 安全なキー管理を実装する 保管中に暗号化を適用する アクセスコントロールを適用する 人をデータから遠ざけるメカニズムを提供する
- 99. 99保管中のデータの管理と保護に関する要件を定義する 例：PCI DSSにおけるデータ保護要件（の一部） • 要件3: 保存されるカード会員データを保護する • 3.4 以下の手法を使用して、すべての保存場所で PAN を少なくとも読み取り不能にする（ポー タブルデジタルメディア、バックアップメディア、ログを含む）。 • （中略） • 関連する鍵管理プロセスおよび手順 を伴う、強力な暗号化 • 3.4.1 （ファイルまたは列レベルのデータベース暗号化ではなく）ディスク暗号化が使用され る場合、論理アクセスはネイティブなオペレーティングシステムの認証およびアクセス制御メ カニズムとは別に管理する必要がある（ローカルユーザアカウントデータベースや一般的な ネットワークログイン資格情報を使用しないなどの方法で）。復号鍵がユーザアカウントと関 連付けられていない。
- 100. 100安全なキー管理を実装する AWS KMS • 暗号鍵の作成、管理、運用のためのサービス •エンベロープ暗号化をサポート（後述） • キーポリシーによるアクセス許可 • キーの利用権限や管理権限をキーポリシーとしてリソース側で制御できる • 必要に応じて他のAWSアカウントに対して許可することも可能 • IAM Access Analyzerによる管理が可能 • 信頼ゾーン外（KMSリソースを持つAWSアカウント外）へのアクセス許可を検出 • 意図的な許可はアーカイブし、意図的ではないアクセス許可を発見 / 排除する
- 101. 101安全なキー管理を実装する エンベロープ暗号化 • AWS EncryptionSDKで用いられる方式 • AWS KMSやAWS CloudHSM等でマスターキーを管理（マスターキーはKMSから出ない） • 暗号化 • 保護対象のデータをデータキーで暗号化 • データキーをマスターキーで暗号化 • 複合 • 暗号化されたデータキーをマスターキーで複合 • 暗号化されたデータをデータキーで複合 Envelope Encryption https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption
- 102. 102保管中に暗号化を適用する 暗号化のアプローチ • Server-side Encryption •データの書き込み時に透過的に暗号化 • S3、EBS、RDS、RedShift などのサービスとの連携をサポート • Client-side Encryption • ユーザーアプリケーションでの暗号化してからデータを保存 • AWS Encryption SDKと連携可能
- 103. 103アクセスコントロールを適用する 例：S3におけるアクセス権限の最小化 • AWSアカウントの外からのアクセス権限はS3 AccessAnalyzerで評価 • データを確実に分離するためにAWSアカウントの分割も検討 • S3で公開データを管理しない場合、アカウントレベルでPublic Access Block を有効化 • サービスの運用管理機能を利用（一部） • バックアップ • バージョニング • ライフサイクル管理（保持期限の定義 / 期限超過後の破棄 など）
- 104. 104人をデータから遠ざけるメカニズムを提供する 例：認証情報 / 鍵の管理 •Parameter Store / Secret Managerに保管し、アプリケーションが必要なタイ ミング（起動時など）に参照 • プログラムや設定ファイルへのハードコードによるリスクの緩和 • EC2インスタンスに対してParameter Store等へのアクセス権をIAM Roleで付 与することによるアクセス制御が可能 その他の例 • 監査証跡となる各種ログの改竄を防ぐためにダッシュボードやクエリのための ツールを提供（生データに直接アクセスさせない） • QuickSight / Athena など
- 105. 105人をデータから遠ざけるメカニズムを提供する 例：データベースの接続情報をParameter Storeで管理 Parameter Storeへのアクセス権を定義 IAMRoleを介して Parameter Storeへのアクセス権を付与 インスタンスメタデータから認証情報を取得 / Parameter Storeから接続情報や暗号化されたデータキーなどを取得
- 106. 106伝送中のデータをどのように保護していますか? 伝送中のデータの保護に関する要件を定義する 安全な鍵および証明書管理を実装する 伝送中に暗号化を適用する データ漏洩の検出を自動化する ネットワーク通信を認証する
- 107. 107伝送中のデータの保護に関する要件を定義する 例：PCI DSSにおけるデータ送信に関する要件（の一部） • 4.1オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送 する場合、以下のような、強力な暗号化とセキュリティプロトコルを使用して 保護する。 • 信頼できる鍵と証明書のみを受け入れる • 使用されているプロトコルが、安全なバージョンまたは構成のみをサポートしている • 暗号化の強度が使用中の暗号化方式に適している
- 108. 108安全な鍵および証明書管理を実装する Certification Managerによる証明書管理 • 無償でサーバー証明書を発行/ 管理 • ただし、CloudFront / ELB / API Gatewayとの連携が前提 （EC2インスタンスに直接展開することはできない） • ドメイン認証をサポート • EV証明書は別途調達してインポートする必要あり • Private CAも別途提供（有償）
- 109. 109伝送中に暗号化を適用する 例：ELB HTTPS ListenerでACMの証明書を利用 あらかじめ作成/ インポートした証明書を選択するだけ
- 110.
- 111. 111伝送中に暗号化を適用する より安全な暗号化プロトコルの利用 • 「Application LoadBalancer および Network Load Balancer に、より厳格な プロトコルと暗号を使用した Forward Secrecy 向けの新しいセキュリティポ リシーを追加」（2019年10月8日） • https://aws.amazon.com/jp/about-aws/whats-new/2019/10/application-load-balancer- and-network-load-balancer-add-new-security-policies-for-forward-secrecy-with-more- strigent-protocols-and-ciphers/ • より厳格なセキュリティ要件に対応 • ELBSecurityPolicy-FS-1-2-2019-08 / ELBSecurityPolicy-FS-1-1-2019-08 / ELBSecurityPolicy-FS-1-2-Res-2019-08 • “This policy (ELBSecurityPolicy-FS-1-2-Res-2019-08) supports TLS 1.2 only and includes only ECDHE (PFS) and SHA256 or stronger (384) ciphers.”
- 112. 112伝送中に暗号化を適用する AWS Site-to-Site VPN •IPsecをサポート
- 113. 113伝送中に暗号化を適用する 要件に応じて以下のような実装も検討 • CloudFrontからカスタムオリジン間を暗号化 • CloudFrontとカスタムオリジンとの間の通信に HTTPS を必須にする • https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/using- https-cloudfront-to-custom-origin.html • RDSとの通信を暗号化 • Using SSL/TLS to Encrypt a Connection to a DB Instance • https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html
- 114. 114データ漏洩の検出を自動化する 例：Macieによるデータアクティビティの監視 • 基本アラートと予測アラートを生成 • 予測アラート •通常のアクティビティとは異なるアクティビティを検知 • 普段は2～3オブジェクトしか操作しない場合に、大量にオブジェクトを操作すると発報する （かもしれない） • 基本アラート • 以下のようなカテゴリーのアラートを提供 • 設定コンプライアンス / データコンプライアンス / ファイルホスティング / サービス障害 / ラ ンサムウェア / 不審なアクセス / ID 列挙 / 特権エスカレーション / 匿名アクセス / オープン 権限 / 場所の異常 / 情報損失 / 認証情報損失
- 115. 115データ漏洩の検出を自動化する 例：VPC FlowLogsでDBインスタンスが通信しているホストを特定 • VPCFlowLogsをCloudWatch LogsもしくはS3に保存 • CloudWatch Logs InsightsもしくはAthenaでクエリを実行して意図しないホ ストとの通信の有無を確認
- 116. 116ネットワーク通信を認証する 例：インターネットVPN（サイト間VPN接続） • 2019年8月16日にVPN接続の認証でACMのPrivate CAから発行したプライベー ト証明書の使用をサポート •「AWS サイト間 VPN で証明書による認証のサポートを開始」 • https://aws.amazon.com/jp/about-aws/whats-new/2019/08/aws-site-to-site-vpn-now-supports- certificate-authentication/ • 概要 • カスタマーゲートウェイを作成するときに証明書を指定（以前は事前共有キー） • Service Linked Roleが必要 • カスタマーゲートウェイデバイスのIPアドレスを指定する必要がない （固定のグローバルIPは不要） 「Site-to-Site VPN Tunnel Authentication Options」 https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-tunnel-authentication-options.html#certificate
- 117. 117ベストプラクティス • Identity andAccess Management（認証・認可） • Detective Controls（発見的統制） • Infrastructure Protection（インフラストラクチャの保護） • Data Protection（データの保護） • Incident Response（インシデントレスポンス）
- 118.
- 119. 119セキュリティインシデントにどのように対応していますか？ 重要な人員と外部リソースを特定する ツールを特定する インシデント対応計画を策定する 封じ込め機能を自動化する フォレンジック機能を確認する アクセスを事前準備する ツールを事前デプロイする ゲームデーを実施する
- 120. 120重要な人員と外部リソースを特定する ずべて自分たちだけで対応できますか？ • 侵害範囲の特定 /証拠の保全 / 根本原因の調査 / 改善策の立案 など • 外部の専門家との協調 • 利害関係者への報告 • 経営者や広報との調整 • 被害の補償 • 弁護士へ対応を委任 • 保険会社へ保険金の請求
- 121. 121ツールを特定する インシデントレスポンスのためのツールの例 • 例：SSM Acquire •SSMを使用して、LinuxインスタンスからS3バケットにメモリを取得します。 • OSQueryを使用してトップ10のIOC(Indicator of Compromise / 攻撃の痕跡)のインスタンスを 調べ、JSON形式で出力し保存します。 • Dockerを使用してマシン上のメモリサンプルを解析する。 • SSMエージェントを実行しているビルドターゲットとしてインスタンスを使用してrekallプロ ファイルを作成します • フォレンジックツールのSSM Acquireを使ってみた #reinvent • https://dev.classmethod.jp/cloud/aws/reinvent2018-ssmacquire/
- 122. 122インシデント対応計画を策定する そもそもどうやってインシデントの発生を認識するのか • イベントの検知（GuardDuty など）/ 外部からの通報 インシデント対応 • 責任者へのエスカレーション • インシデントの範囲を特定、事実関係の整理 • 証拠の保全 / 問題の緩和や修復 （侵害されたリソースの隔離、サービスの停止、認証情報の無効化、など） • サービス利用者など利害関係者への報告・広報 • サービスの原状回復、暫定対応 / 根本原因調査および対策 • 被害の補償
- 123. 123封じ込め機能を自動化する 想定される封じ込め方法 • 例：Security GroupもしくはNACLによる遮断/ ELBからデタッチ • 調査のために必要な経路のみを確保 • 他のリソースに与える影響に留意 • 想定可能な手順はスクリプトで自動化 など • 根本原因調査のためのクリーンルーム（隔離されたVPC） • 取得したフォレンジックディスクイメージ（AMI）を展開 / 詳細な調査 • CloudFormationなどで展開できるとスムーズ • 【注意】インスタンスの停止は（少なくとも）証拠の保全後に実施 • ライブレスポンス / メモリ収集 / フォレンジックディスクイメージなど必要な措置を先に実施
- 124. 124フォレンジック機能を確認する ツールや外部調査会社の能力を確認 • インシデントの範囲特定 /証拠保全 / 根本原因の特定と改善などを実行する必 要がある • ツールおよび外部の専門家がこれらを実現できるか事前に確認
- 125. 125アクセスを事前準備する 事前準備 • インシデントレスポンスを実行するメンバーに対するユーザーの発行 • 役割に応じた権限の事前定義 •後述するサービスの利用に必要な権限を整理 • 関係者とのコミュニケーション手段の整理 • 例：Slackなどのチャットサービス / 報告書のフォーマットの整備 など
- 126. 126ツールを事前デプロイする インシデントの検知とレスポンスに利用できるAWSサービス（一部） • CloudTrail /CloudTrail Insights（アクティビティの収集 / 保存 / 分析） • VPC FlowLogs（ネットワークフローログ） • GuardDuty（脅威検知） • IAM Access Analyzer / S3 Access Analyzer（意図しないアクセス権の特定） • Macie（データの分類とアクティビティの監視） • Amazon Detective（アクティビティの分析） • Systems Manager（EC2インスタンスに対するオペレーション） • WAF / API Gateway / CloudFront / ELB（アクセスログの収集） • S3 / Athena / CloudWatch Logs（ログの参照 / 分析） • IAM（認証情報の無効化 / 再発行） • Security Hub（セキュリティイベントの集約）
- 127. 127ゲームデーを実施する GameDayとは？ • AWS環境が与えられる • そこに攻撃や障害など様々なイベントが発生 •環境を維持することでポイントが貰えるので、チームでポイントを競う • AWS GameDayに初参加してみた【AWS GameDay Microservices Madness@AWS Loft Tokyo】 • https://dev.classmethod.jp/etc/aws-gameday-microservices/
- 128.
- 129. 129まとめ フレームワークを用いて現状を網羅的に評価 • AWSのことだけでなく、脅威モデリングや要件定義 /インシデントレスポン スなどに対する質問もある • 改善にあたり、セキュリティ以外の観点（柱）も考慮 ビジネス上の要件を踏まえて優先度を設定 • 投資できる金額や優先すべき課題はビジネスによって異なる • ビジネス環境自体も変化する • 技術的な観点だけで最適な対策を決定することはできない 継続的な評価と改善 • 定期的にレビュー・改善を実施することが重要
- 130.
- 131. 131参考資料 クレジットカード取引におけるセキュリティ対策の強化に向けた「実行 計画2019」を取りまとめました • https://www.meti.go.jp/press/2018/03/20190304004/20190304004.html AWS Well-ArchitectedFramework • https://wa.aws.amazon.com/index.en.html PCI DSS • https://www.pcisecuritystandards.org/document_library PCI DSS: Looking Ahead to Version 4.0 • https://blog.pcisecuritystandards.org/pci-dss-looking-ahead-to-version-4.0
- 132. 132参考資料 NIST Special Publication800-63B / Digital Identity Guidelines • https://pages.nist.gov/800-63-3/sp800-63b.html ゼロトラストネットワーク - 境界防御の限界を超えるためのセキュアな システム設計 • https://www.oreilly.co.jp/books/9784873118888/ Threat Modeling: ソフトウェアの脅威を洗い出す手法 • https://qiita.com/takutoy/items/688b6b0517003f35e79a CLOUD SECURITY POSTURE REPOSITORY (CSPR) • https://gsl.dome9.com/
- 133.