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.

Well-Architected Framework Security Pillar Deep Dive ~セキュリティからはじめるより良い設計~

2,149 views

Published on

Well-Architected Framework Security Pillar Deep Dive ~セキュリティからはじめるより良い設計~

Published in: Technology
  • Hi there! I just wanted to share a list of sites that helped me a lot during my studies: .................................................................................................................................... www.EssayWrite.best - Write an essay .................................................................................................................................... www.LitReview.xyz - Summary of books .................................................................................................................................... www.Coursework.best - Online coursework .................................................................................................................................... www.Dissertations.me - proquest dissertations .................................................................................................................................... www.ReMovie.club - Movies reviews .................................................................................................................................... www.WebSlides.vip - Best powerpoint presentations .................................................................................................................................... www.WritePaper.info - Write a research paper .................................................................................................................................... www.EddyHelp.com - Homework help online .................................................................................................................................... www.MyResumeHelp.net - Professional resume writing service .................................................................................................................................. www.HelpWriting.net - Help with writing any papers ......................................................................................................................................... Save so as not to lose
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Get Paid To Write Articles? YES! View 1000s of companies hiring online writers now! ●●● https://tinyurl.com/vvgf8vz
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Well-Architected Framework Security Pillar Deep Dive ~セキュリティからはじめるより良い設計~

  1. 1. Well-Architected Framework Security Pillar Deep Dive ~セキュリティからはじめるより良い設計~ AWS事業本部 中山順博
  2. 2. スライドは後で入手することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター音が出ないようにご配慮ください
  3. 3. 3本セッションについて • 中級向けのセッションです • IAMの基本的な機能解説などは「しません」 • セキュリティの基礎やAWSのセキュリティ機能をある程度ご存じであること を前提としています • 比較的新しい機能を紹介します • 関連セッション • 「AWSでのセキュリティ対策全部盛り[初級から中級まで]」を Developers.IO 2019 TOKYOで発表しました #cmdevio • https://dev.classmethod.jp/cloud/aws/developers-io-2019-tokyo-all-security-in- aws/
  4. 4. 4 本セッションは特盛くらいです
  5. 5. 5Agenda • Well-Architected Framework • 設計原則 • ベストプラクティス • まとめ
  6. 6. 6 Well-Architected Framework
  7. 7. 7Well-Architected Frameworkとは? システム設計および運用に関する考え方・ベストプラクティス • AWSのソリューションアーキテクトとユーザーの経験に基づく • 5つの柱でシステムを捉える (セキュリティ、信頼性、運用性、パフォーマンス、コスト) • それぞれの柱の考え方に基づいて評価対象のシステムをレビュー(質問形式) • 詳細はホワイトペーパーを参照 • https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf
  8. 8. 8Well-Architected Frameworkとは? レビューの進め方 • CTO、アーキテクト、開発者、運用チームメンバーなど可能な限り全ての関係 者が参加してもらう • 必要に応じてソリューションアーキテクトがレビューをサポート (慣れたらWell-Architected ToolでのセルフチェックもOK) • W-Aに基づくレビューは監査ではない (現状を踏まえて今後どうするかを考える機会) • ビジネス要件を踏まえて改善の優先度を設定 (何を優先するかユーザーが決める必要がある / 全てのベストプラクティスに 準拠する必要はない) • プロジェクトの早い段階で実施することを推奨 (問題の発生を予防 / もちろんリリース後のアセスメントにも利用可能)
  9. 9. 9 設計原則
  10. 10. 10(セキュリティに関する)設計原則 • Implement a strong 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(セキュリティイベントに備える)
  11. 11. 11強固な認証基盤 認証要素 • 知識、所有、生体の組み合わせ(パスワード認証は「知識」のみ) IDのライフサイクル管理 • 異動や退職などのイベントに合わせた権限の変更やIDの失効など 認容要素の強度 • パスワードの複雑さ、複製のしにくさ、など 最小権限 • 職務定義とそれに必要な権限
  12. 12. 12トレーサビリティの担保 アクティビティの収集 • 例:AWSのAPIに対するリクエストのログ(CloudTrail) アクティビティの監視、重要なイベントの検知 • 例:インスタンスメタデータから取得したクレデンシャルがVPC外から利用さ れた 不正なイベントへの対応 • 例:セッションの無効化
  13. 13. 13全てのレイヤーの保護 Attack Surface • 人、ファシリティ、ネットワーク、OS、ミドルウェア、アプリケーショ ン・・・ • 攻撃者はどこか一つの穴を足がかりに目的を達成しようとする 多層防御 • 恒久的に完全な対策は存在しない • 複数の対策を組み合わせる必要がある
  14. 14. 14自動化 セキュリティイベントへの対応 • 大規模化・高度化する攻撃を一組織だけで対応することは一般的に困難 • 人がボトルネックにならない対策が必要 セキュリティリスクを抑制 • 設計通りに設定されていないリスクを排除(設定を自動化) • 設計・設定自体が適切でないリスクを排除(評価 / 是正の自動化)
  15. 15. 15保存・転送時のデータ保護 データの分類 • 機密性の高いデータに対する要件に合わせるのは効率が悪い データの保護 • データの重要度に応じて、暗号化 / アクセス制御(権限管理) / トークン化な どの保護を実施
  16. 16. 16人からデータを遠ざける データを人が直接扱うリスク • 誤った変更や削除 • 改竄 • クレデンシャルの漏洩 / 搾取からの情報漏洩 ツールを介したデータ利用 • データに対する操作を規定 / 制限することでリスクを回避 / 緩和
  17. 17. 17セキュリティイベントに備える もしセキュリティイベントが起こったら・・・ • イベントの検知/外部からの通報 • 現状調査 • 責任者へのエスカレーション • 問題の緩和(侵害されたリソースの隔離、サービスの停止など) • 利用者など利害関係者への報告・広報 • サービスの原状回復、暫定対応 • 根本原因調査および対策 • 被害の補償
  18. 18. 18 考えることは腐るほどある
  19. 19. 19 ベストプラクティス
  20. 20. 20ベストプラクティス • Identity and Access Management(認証・認可) • Detective Controls(発見的統制) • Infrastructure Protection(インフラストラクチャの保護) • Data Protection(データの保護) • Incident Response(インシデントレスポンス)
  21. 21. 21認証・認可 SEC 1. 認証情報と認証をどのように管理していますか? SEC 2. 人為的なアクセスをどのように制御していますか? SEC 3. プログラムによるアクセスをどのように制御していますか?
  22. 22. 22認証情報と認証をどのように管理していますか?  アイデンティティおよびアクセス管理要件を定義する  AWS ルートユーザーを保護する  Multi-Factor Authentication (MFA) の使用を義務化する  アクセスコントロールの義務化を自動化する  一元化されたフェデレーションプロバイダーと統合する  パスワード要件を義務化する  認証情報を定期的にローテーションする  認証情報を定期的に監査する
  23. 23. 23Multi-Factor Authentication (MFA) の使用を義務化する AWS IAMにおけるMFA • IAM Userに対して所有物による認証を追加できる • TOTP(RFC6238)およびU2Fに対応
  24. 24. 24 どのように展開するか?
  25. 25. 25Multi-Factor Authentication (MFA) の使用を義務化する MFAは利用者自身で有効化できる • iam:CreateVirtualMFADevice / iam:EnableMFADeviceなどの権限が必要 • ポリシー変数を利用して自身のIAM Userのみに許可できる MFAが追加されていない状態で特権を行使されるリスクは? • 以下の要素で対応可能 • IAM PolicyのNotAction / Condition要素 • IAM RoleのTrust Policy
  26. 26. 26Multi-Factor Authentication (MFA) の使用を義務化する 自身のMFAデバイスを自己管理する権限 + (業務で必要な権限を持った)IAM Roleを引き受ける権限 IAM UserがMFAを利用してログインしている場合に 権限を委譲する IAM UserがMFAを利用してログインしている場合に 権限を委譲する
  27. 27. 27Multi-Factor Authentication (MFA) の使用を義務化する { "Sid": "BlockMostAccessUnlessSignedInWithMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:ListMFADevices", "iam:ListUsers", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } 多要素認証を利用してログインしていないとき これらのアクション「以外」 (MFAデバイスの有効化「以外」) 実行を許可しない IAM: Allows IAM Users to Self-Manage an MFA Device より抜粋 https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_mfa-selfmanage.html IAM User
  28. 28. 28Multi-Factor Authentication (MFA) の使用を義務化する Policy Evaluation Logic https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html Denyが優先
  29. 29. 29Multi-Factor Authentication (MFA) の使用を義務化する { "Sid": "AllowIndividualUserToManageTheirOwnMFA", "Effect": "Allow", "Action": [ "iam:CreateVirtualMFADevice", "iam:DeleteVirtualMFADevice", "iam:EnableMFADevice", "iam:ResyncMFADevice" ], "Resource": [ "arn:aws:iam::*:mfa/${aws:username}", "arn:aws:iam::*:user/${aws:username}" ] } ログインしているIAM User およびMFAデバイスに対して これらのアクション (MFAデバイスの有効化) 実行を許可する IAM: Allows IAM Users to Self-Manage an MFA Device より抜粋 https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_mfa-selfmanage.html IAM User
  30. 30. 30Multi-Factor Authentication (MFA) の使用を義務化する { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } } } 多要素認証を利用してログインしてる IAM Userであれば 特定のAWSアカウントに対して 権限の委譲を許可する Creating a Role to Delegate Permissions to an IAM User より抜粋 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html IAM Role
  31. 31. 31Multi-Factor Authentication (MFA) の使用を義務化する IAM User { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "*" ] } ] } 任意のIAM Roleに対して Assume Roleを実行できる (IAM Roleに信頼されていることが前提)
  32. 32. 32Multi-Factor Authentication (MFA) の使用を義務化する Policy Evaluation Logic https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html Trust Policyはリソースポリシーの一種
  33. 33. 33アクセスコントロールの義務化を自動化する マルチアカウント環境におけるIAMの管理
  34. 34. 34アクセスコントロールの義務化を自動化する マルチアカウント環境におけるIAMの管理 ?!
  35. 35. 35アクセスコントロールの義務化を自動化する マルチアカウント管理の課題(の一部) • 組織のセキュリティポリシーをAWSアカウントに「正しく」反映させること • Organization SCPによるアカウント単位でのアクセス制御 • IAMの管理者に負担が集中 • Permission boundaryによる権限の委任
  36. 36. 36アクセスコントロールの義務化を自動化する AWS Organizations • 複数のAWSアカウントを集中管理 • 料金の支払およびアクセス制御が可能 • 1つの「組織」を定義し、AWSアカウントを組織に参加させる • OU(組織単位)でAWSアカウントをグループ化できる • 組織は階層構造のOUとそれに所属するAWSアカウントで構成される • OUもしくはAWSアカウントにSCP(サービスコントロールポリシー)を適用 できる • 上位のOUに割り当てられたSCPは下位のOUに継承される ※ Landing Zoneの考え方に基づき、CloudFormation(StackSet)でIAM Role / Policyを展開するアプローチも考えられるがここでは割愛
  37. 37. 37アクセスコントロールの義務化を自動化する AWS Organizations の用語と概念 https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_getting-started_concepts.html
  38. 38. 38アクセスコントロールの義務化を自動化する Permission Boundary(以降、境界) • IAM Entity(IAM User / Role)に割り当てることができる追加のポリシー(ポリ シー自体はManaged Policyとして定義) • 従来のポリシー(Managed PolicyおよびInline Policy)と境界の両方で許可さ れたアクションを実行可能
  39. 39. 39アクセスコントロールの義務化を自動化する 例:境界を応用したIAM管理権限の委譲 • 単純にIAMの管理権限を付与すると、IAM管理者が増えるリスクがある • 「信頼」できるメンバーは組織内に多くいるわけではない・・・ • 境界を利用してIAM管理の「範囲」を制御できる • 「特権昇格」を防ぐ • 境界内での権限付与は委任された管理者の裁量で決定(ここ重要)
  40. 40. 40アクセスコントロールの義務化を自動化する ユースケース とあるチームに対して以下のことを委 任したい • IAM Userの作成 • チームでの業務に必要な権限の付与
  41. 41. 41アクセスコントロールの義務化を自動化する 1. メンバー用の境界を定義 メンバーが利用してよい最も広い権限を境界用ポリシーと して定義 2. IAM管理者用の境界を定義 IAM Entityを作成するときに前の手順で作成した境界用の ポリシーの設定を条件にした境界用ポリシーを定義し、 IAM管理者に割り当て(境界の設定を強制 etc) 3. IAM管理者用の権限を付与 IAMの管理権限を付与(2のポリシーが最小権限であれば、 ここでは”iam:*”など大雑把に許可してOK) 4. IAM管理者用にIAMの管理を委任 IAM管理者の判断でIAM Userの発行と権限の付与を実施 (境界の設定が必須なので、どのようなポリシーを割り当 てても境界以上の権限は行使できない)
  42. 42. 42アクセスコントロールの義務化を自動化する 1.メンバー用の境界を定義(例) { "Effect": "Allow", "Action": [ "cloudwatch:*", "ec2:*", "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:ChangePassword", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] } 「アクセス許可の境界を使用した他のユーザーへの責任の委任」の一部を抜粋・改変 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate チームで必要な権限(最大)を定義 認証情報の自己管理に必要な権限
  43. 43. 43アクセスコントロールの義務化を自動化する 2.IAM管理者用の境界を定義(例) { "Sid": "CreateOrChangeOnlyWithBoundary", "Effect": "Allow", "Action": [ "iam:CreateUser", "iam:DeleteUserPolicy", "iam:AttachUserPolicy", "iam:DetachUserPolicy", "iam:PutUserPermissionsBoundary" ], "Resource": "*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/XCompanyBoundaries" } } } 「アクセス許可の境界を使用した他のユーザーへの責任の委任」の一部を抜粋・改変 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate IAM Userに対する管理操作を行う場合、 指定したポリシーが境界として指定されている必要がある (手順1で作成したポリシー)
  44. 44. 44アクセスコントロールの義務化を自動化する 2.IAM管理者用の境界を定義(例) 「アクセス許可の境界を使用した他のユーザーへの責任の委任」の一部を抜粋・改変 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate { "Sid": "NoBoundaryPolicyEdit", "Effect": "Deny", "Action": [ "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": [ "arn:aws:iam::123456789012:policy/XCompanyBoundaries", "arn:aws:iam::123456789012:policy/DelegatedUserBoundary" ] } 境界用のポリシーの管理を禁止 (手順1および2で作成したポリシー)
  45. 45. 45アクセスコントロールの義務化を自動化する 2.IAM管理者用の境界を定義(例) 「アクセス許可の境界を使用した他のユーザーへの責任の委任」の一部を抜粋・改変 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate { "Sid": "NoBoundaryUserDelete", "Effect": "Deny", "Action": "iam:DeleteUserPermissionsBoundary", "Resource": "*" } ユーザーから境界を削除することを禁止
  46. 46. 46アクセスコントロールの義務化を自動化する 3.IAM管理者用の権限を付与(例) 「アクセス許可の境界を使用した他のユーザーへの責任の委任」の一部を抜粋・改変 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate { "Sid": "IAM", "Effect": "Allow", "Action": "iam:*", "Resource": "*" } IAMの管理権限を付与 (境界以上の権限は行使できない)
  47. 47. 47アクセスコントロールの義務化を自動化する 4.IAM管理者用によるIAM Userの管理 • IAM Userを作成する際などに境界を必ず設定する • 許可するStatementのConditionで指定されているので、設定しないと作成できない • どのようなポリシーを割り当てても境界以上の権限を行使することはできない
  48. 48. 48人為的なアクセスをどのように制御していますか?  人為的なアクセス要件を定義する  最小限の権限を付与する  各個人に一意の認証情報を割り当てる  ユーザーライフサイクルに基づいて認証情報を管理する  認証情報管理を自動化する  ロールまたはフェデレーションを通じてアクセス権を付与する
  49. 49. 49認証情報管理を自動化する 認証情報のライフサイクル • 入社 / 異動(入) / プロジェクトへの参画 など • IDの発行 / 権限の付与 • プロジェクト内での職務の変更 • 権限の変更 • 退社 / 異動(出) / プロジェクトからの離脱 など • IDの失効 ← やらなくても業務に支障が無いのでサボりがち
  50. 50. 50認証情報管理を自動化する Automated IAM User Cleanup • GitHubで公開 • awslabs/aws-well-architected-labs • https://github.com/awslabs/aws-well-architected- labs/tree/master/Security/200_Automated_IAM_User_Cleanup • 長期間利用されていないユーザー / 認証情報(パスワード・アクセスキー)を 自動で削除 / 無効化 / レポート • SAMでデプロイ
  51. 51. 51認証情報管理を自動化する Automated IAM User Cleanup
  52. 52. 52認証情報管理を自動化する Automated IAM User Cleanup
  53. 53. 53ロールまたはフェデレーションを通じてアクセス権を付与する マルチアカウント管理の課題(の一部) • 適切に設計しないと認証情報が増える • 例:(アクセスキー / パスワード / MFA Device)× AWSアカウント
  54. 54. 54ロールまたはフェデレーションを通じてアクセス権を付与する Switch Role • マネージメントコンソールにログイ ンしたユーザーがIAM Roleの権限に 切り替えること • 切り替え元のIAM User / AWSカウ ントを信頼しているRoleに切り替え ることが可能 • AWSアカウントを横断できる Switching to a Role (Console) https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
  55. 55. 55プログラムによるアクセスをどのように制御していますか?  プログラムによるアクセス要件を定義する  最小限の権限を付与する  認証情報管理を自動化する  各コンポーネントに一意の認証情報を割り当てる  ロールまたはフェデレーションを通じてアクセス権を付与する  動的認証を実装する
  56. 56. 56動的認証を実装する STS(Security Token Service) • 一時的な認証情報をリクエストする ためのサービス • IAM Roleが信頼する様々なエンティ ティに対して一時的な認証情報を発 行 • マネージメントコンソール上でス イッチロールするためにも利用 STS API Reference https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html
  57. 57. 57動的認証を実装する なぜ認証情報をローテーションするべきなのか? • 認証情報が漏洩したときに被害を抑止できる • ローテーションできるようにしておくことが重要 • STSで発行した一時的な認証情報が漏洩した場合 • セッションを無効化することが可能 • 管理者が気がつかなかった場合でも被害はセッションの有効期限まで • 総当たりなどで突破されるリスクを緩和 • (そもそもシークレットアクセスキーは十分長い)
  58. 58. 58動的認証を実装する 例:IAM Roleのセッション無効化
  59. 59. 59動的認証を実装する 一時的な認証情報の取得方法は主に2つ 1. AWS STS API (AssumeRole等) • 明示的に取得 2. (EC2の場合)Instance Metadata • Amazon EC2 インスタンスでの一時的な認証情報の使用 • 「インスタンスで実行されるアプリケーション、AWS CLI、Tools for Windows PowerShell コマンドが インスタンスメタデータから自動的に一時的セキュリティ認証情報を取得できるようになります。一時的 セキュリティ認証情報を明示的に取得する必要はありません。AWS SDK、AWS CLI、Tools for Windows PowerShell によって自動的に EC2 インスタンスメタデータサービスから認証情報が取得され て使用されます。」 • https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_use- resources.html#using-temp-creds-sdk-ec2-instances
  60. 60. 60動的認証を実装する Instance Metadata $ 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" }
  61. 61. 61発見的統制 SEC 4. セキュリティイベントをどのように検出し、調査していますか? SEC 5. 新しいセキュリティ脅威に対してどのように防御していますか?
  62. 62. 62セキュリティイベントをどのように検出し、調査していますか?  ログの要件を定義する  メトリクスの要件を定義する  アラートの要件を定義する  サービスとアプリケーションのログ記録を設定する  ログを一元的に分析する  主要な指標に関するアラートを自動化する  調査プロセスを開発する
  63. 63. 63サービスとアプリケーションのログ記録を設定する まずはログの取得から • ログが無いと何も分からない AWSで取得できる各種ログ • CloudTrail • VPC FlowLogs • Access Log (CloudFront, WAF, ELB, API Gateway, S3 etc…) • Audit Log (RDS, Redshift etc…) • OS / Middleware / Application Log(S3 / Logsなどに保存)
  64. 64. 64主要な指標に関するアラートを自動化する 様々なセキュリティイベント • 特定IPアドレス / 不特定多数から大量のリクエスト (DoS / DDoS) • マルウェアに感染 • C&Cサーバーへのデータ送信 • 認証情報の漏洩 / 搾取 • 不正ログインの試行 • 他多数・・・
  65. 65. 65主要な指標に関するアラートを自動化する GuardDutyで定義されたイベントを通知 • AWS上のアクティビティを機械学習で分析・脅威検知 • 情報ソースはCloudTrail / VPC Flow Logs / DNS Query • 検知できるイベントの一覧 • https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html • 例:Backdoor:EC2/C&CActivity.B!DNS • 既知のC&Cサーバーのホスト名をDNSに問い合わせ
  66. 66. 66主要な指標に関するアラートを自動化する 例:PCI DSS v3.2 • 要件 8.1.6に以下のような要件がある • 「6 回以下の試行で、ユーザ ID をロックアウトすることによって、アクセス試行の繰り返し を制限する。」 • 要件通りのロックアウトはできないが、検知は可能 • CloudTrailでマネージメントコンソールの認証エラーを記録 • CloudWatch Logsのメトリクスフィルターで一定頻度の認証エラーを検知 • https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudwatch-alarms-for- cloudtrail.html#cloudwatch-alarms-for-cloudtrail-signin { ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }
  67. 67. 67ログを一元的に分析する 様々な分析手段 • Elasticsearch Service、Athena/QuickSight、CloudWatch Insights、3rd Party (SumoLogic etc) 選択基準 • コスト(料金、学習)、想定利用シーン、サポートするログの形式、など • 「Amazon Athena,Amazon CloudWatch Logs Insightsの使い分けについて考 えてみる」 • https://dev.classmethod.jp/cloud/aws/how-to-use-amazon-athena-amazon-cloudwatch-logs- insights/
  68. 68. 68ログを一元的に分析する 例:SumoLogic あやしいAWSコンソールログインを監視するダッシュボードをSumoLogicで作ってみる https://dev.classmethod.jp/cloud/aws/sumologic_custom_dashboard/ _sourceCategory = cloudtrail | json "userAgent","errorCode" | json "userIdentity.userName" as userName| parse "¥"eventName¥":¥"*¥"" as event_name | parse regex field=event_name "^(?<event_type>[A-Z][a-z]+?)[A-Z]" | count by userName, userAgent, event_type,errorCode | where _count > 10 | sort _count
  69. 69. 69新しいセキュリティ脅威に対してどのように防御していますか?  組織要件、法的要件、コンプライアンス要件に関する最新情報を入手する  セキュリティのベストプラクティスに関する最新情報を入手する  セキュリティ脅威に関する最新情報を入手する  新しいセキュリティサービスとセキュリティ機能を定期的に評価する  脅威モデルを使用してリスクを定義し優先順位付けする  新しいセキュリティサービスとセキュリティ機能を実装する
  70. 70. 70組織要件、法的要件、コンプライアンス要件に関する最新情報を入手する 例:PCI DSS 4.0 • 2020年末頃にリリースが予定されている • NISTのガイダンス (NIST SP 800-63) に基づいてパスワードに関する要件が変 更されるもよう • パスワードの複雑さ・定期変更の要否、多要素認証について • 「PCI DSS: Looking Ahead to Version 4.0」 • https://blog.pcisecuritystandards.org/pci-dss-looking-ahead-to-version-4.0 PCI DSS v4.0 will incorporate input received from global PCI SSC stakeholders during the 2017 request for comments (RFC) period. Some of the specific areas that stakeholders asked PCI SSC to review include: - Authentication, specifically consideration for the NIST MFA/password guidance - (以下、割愛)
  71. 71. 71セキュリティ脅威に関する最新情報を入手する Capital Oneにおけるセキュリティインシデントの概要 • 独自運用のWAFで設定不備 / SSRF攻撃を受け、認証情報を窃取 (有効と思われる)対策 • 認証上の不正利用を検知 • S3にバケットポリシーを追加 (特定VPCからのアクセスに限定) • S3上のデータの識別 / 分類 • IAM Roleの権限最小化 • WAFの独自運用を停止 (サービスの利用 など) SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた https://piyolog.hatenadiary.jp/entry/2019/08/06/062154
  72. 72. 72セキュリティ脅威に関する最新情報を入手する UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration • Credentials that were created exclusively for an EC2 instance through an instance launch role are being used from an external IP address. (インスタンス起動ロールを通じて EC2 インスタンス専用に作成された認証 情報が外部 IP アドレスから使用されています。)
  73. 73. 73セキュリティ脅威に関する最新情報を入手する
  74. 74. 74セキュリティ脅威に関する最新情報を入手する 特定のVPCからのみアクセスを許可するS3 Bucket Policy { "Version": "2012-10-17", "Statement": [ { "Principal": "*", "Action": "s3:*", "Effect": "Deny", "Resource": ["arn:aws:s3:::examplebucket", "arn:aws:s3:::examplebucket:*"], "Condition": { "StringNotEquals": { "aws:sourceVpc": "vpc-111bbb22" } } } ] } Amazon S3 の VPC エンドポイント用のバケットポリシーの例 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html
  75. 75. 75脅威モデルを使用してリスクを定義し優先順位付けする 脅威モデル? • 「脅威モデリングは、開発対象のソフトウェアがどのようなセキュリティ脅威 にさらされており、攻略される可能性を持ちうるかを洗い出す活動である。」 • 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(特権昇格)
  76. 76. 76インフラストラクチャの保護 SEC 6. ネットワークをどのように保護していますか? SEC 7. コンピューティングリソースをどのように保護していますか?
  77. 77. 77ネットワークをどのように保護していますか?  ネットワーク保護要件を定義する  露出を制限する  設定管理を自動化する  ネットワーク保護を自動化する  検査および保護を実装する  すべてのレイヤーでトラフィックをコントロールする
  78. 78. 78設定管理を自動化する Firewall Manager • AWS WAF / Shield Advancedの設定をAWSアカウント横断で展開することが 可能 • OrganizationsおよびConfigの有効化が前提 • Security Groupも新たにサポート • SecurityGroupの割り当て / 評価 / 未使用やスコープの重複の検出 など • 「AWS Firewall Manager の最新情報 – VPC Security Groups のサポート」 • https://aws.amazon.com/jp/blogs/news/aws-firewall-manager-update-support-for-vpc-security- groups/
  79. 79. 79ネットワーク保護を自動化する AWS WAF Managed Rule • AWS WAF自体はセルフサービス(ユーザー自身でルールを定義) • 一定のスキルが必要 • Managed Ruleとしてパートナーからルールの提供を受けることが可能 • Cyber Security Cloud, F5, Fortinet, Imperva, Trend Micro, Trustwave
  80. 80. 80ネットワーク保護を自動化する DDoSに対する影響の緩和 • StandardとAdvanceの2種類のサービスを提供 • Standard • CloudFront / Route53のエッジロケーションでL3 / L4レイヤーの攻撃を自動緩和 • 無料 / 設定なし • Advance • L7レイヤーへの攻撃の緩和 • DRT(DDoS Response Team)によるサポート(WAFのカスタムルール作成など) • Cost Protection • Reporting(CloudWatchメトリクスの有効化 / 通知)
  81. 81. 81検査および保護を実装する Config Rulesによる検査と保護 • Configで管理できるリソースを評価 / 適切な状態へ是正することが可能 • 多数のルールが事前定義済 / Lambdaで独自実装することも可能 • Systems Manager Automation Documentで是正する手順を定義 • 自動的な是正も可能 • 「AWS Config ルールを使用してコンプライアンス違反のリソースを自動的に修正する」 • https://aws.amazon.com/jp/about-aws/whats-new/2019/09/use-aws-config-rules-to-automatically- remediate-non-compliant-resources/
  82. 82. 82検査および保護を実装する Config Rulesの事前定義済ルール(ネットワーク関連) • Network and Content Delivery • alb-http-to-https-redirection-check • api-gw-cache-enabled-and-encrypted • api-gw-endpoint-type-check • cloudfront-viewer-policy-https • internet-gateway-authorized-vpc-only • vpc-default-security-group-closed • vpc-flow-logs-enabled • vpc-sg-open-only-to-authorized-ports • vpc-vpn-2-tunnels-up HTTP から HTTPS へのリダイレクトが ALBのすべての HTTP リスナーで 設定されているかどうかを確認 任意のIPアドレス (0.0.0.0/0) からのアクセス許可を持つ セキュリティグループで、 指定したインバウンド TCP / UDP トラフィックのみが 許可されるかどうかを確認 指定されたVPCにのみ Internet Gatewayがアタッチされているかどうかを確認
  83. 83. 83コンピューティングリソースをどのように保護していますか?  コンピューティング保護要件を定義する  脆弱性をスキャンし、パッチを適用する  設定管理を自動化する  コンピューティング保護を自動化する  IPS / IDS 等  攻撃領域を削減する  OS / Middlewareの管理が不要なサービス(Lambda など)  マネージドサービスを活用する  バックアップ、パッチ適用が自動化されているサービスの利用(RDS、DynamoDB など)
  84. 84. 84脆弱性をスキャンし、パッチを適用する パッチ適用の課題(OS / ミドルウェア) • パッチ適用前の検証コスト • 優先度をつけて順番に対処したいが、どのように優先度を決めるべきかが難しい • Systems Manager Patch Manager / Inspectorでも脆弱性の検知は可能だが、 上記の課題が残る
  85. 85. 85脆弱性をスキャンし、パッチを適用する 例:FutureVulsによる脆弱性のトリアージ • リスクを受容できる条件を定義 / フィルタリング • 攻撃コードの有無 / ネットワーク経由での攻撃可否 / 認証情報の要否 等 • パッチが提供されていない脆弱性を一時的に非表示 • パッチが提供されたら再表示することが可能 • DeepSecurity as a Serviceとの連携 • 「検知した脆弱性がDSaaSの侵入防御機能で防御されているかをFutureVulsの画面上に表示」 • FutureVuls > RELEASE NOTE > 2019-09-19 リリース内容 • https://releasenote.vuls.biz/release-note/20190919/
  86. 86. 86脆弱性をスキャンし、パッチを適用する
  87. 87. 87設定管理を自動化する Infrastructure as Code • 大規模な環境でも、コード化した通りに環境を構築できる • CloudFormation / Terraform / Ansible 等 • マネージメントコンソールなど対話的な設定方法よりミスをするリスクは軽減できる • ただし、コードが間違っている / 設計が正しいかは別問題
  88. 88. 88設定管理を自動化する 責任共有モデル AWSを適切に設定することはユーザーの責任
  89. 89. 89設定管理を自動化する CloudFormationテンプレートのセキュリティチェックツール(例) • OSS • cfn-nag : https://github.com/stelligent/cfn_nag https://dev.classmethod.jp/cloud/aws/introduction-cfn-nag/ • 商用製品 • Dome9 (preview) : https://sc1.checkpoint.com/documents/CloudGuard_Dome9/Documentation/Compliance- and-Governance/CFTAssessment.html https://gsl.dome9.com/
  90. 90. 90設定管理を自動化する cfn-nagの評価対象(例) • 任意のAction • 任意のPrinciple AWSTemplateFormatVersion: "2010-09-09" Description: A sample template for cfn-nag Resources: S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: TestBucket BucketPolicy: Type: "AWS::S3::BucketPolicy" Properties: Bucket: Ref: "S3Bucket" PolicyDocument: Statement: - Action: - "s3:*" Effect: "Allow" Resource: "*" Principal: "*"
  91. 91. 91設定管理を自動化する cfn-nagの評価結果(例) ------------------------------------------------------------ cfn-nag.yml ------------------------------------------------------------------------------------------------------------------------ | FAIL F15 | | Resources: ["BucketPolicy"] | | S3 Bucket policy should not allow * action ------------------------------------------------------------ | FAIL F16 | | Resources: ["BucketPolicy"] | | S3 Bucket policy should not allow * principal Failures count: 2 Warnings count: 0
  92. 92. 92データの保護 SEC 8. データをどのように分類していますか? SEC 9. 保管中のデータをどのように保護していますか? SEC 10. 伝送中のデータをどのように保護していますか?
  93. 93. 93データをどのように分類していますか?  データ分類要件を定義する  データ保護コントロールを定義する  データの識別を実行する  データストアやデータオブジェクトへのタグ付 など  識別および分類を実装する  データのタイプを特定する
  94. 94. 94識別および分類を実装する Amazon Macieによるデータ管理 • できること • データの検出と分類 • データのアクティビティを監視 / 不審なアクティビティ発生時にアラート • データの可視化(分類、アクティビティ) 分類手法 • コンテンツタイプ / ファイル拡張子 / テーマ / 正規表現 / 個人情報(PII) / SVMベースの分類 • 「Amazon Macie でデータを分類する」 • https://docs.aws.amazon.com/ja_jp/macie/latest/userguide/macie-classify-data.html
  95. 95. 95識別および分類を実装する クレジットカード情報 個人情報
  96. 96. 96保管中のデータをどのように保護していますか?  保管中のデータの管理と保護に関する要件を定義する  安全なキー管理を実装する  保管中に暗号化を適用する  アクセスコントロールを適用する  人をデータから遠ざけるメカニズムを提供する
  97. 97. 97保管中のデータの管理と保護に関する要件を定義する 暗号化の分類 • サーバーサイド暗号化 • データストア(サーバー)に保存する際に透過的に暗号化 • クライアントサイド暗号化 • アプリケーション(クライアント)がデータストアにデータを送信する前に暗号化
  98. 98. 98安全なキー管理を実装する AWS KMS • 暗号鍵の作成、管理、運用のためのサービス • Server-side Encryption • データの書き込み時に透過的に暗号化 • S3、EBS、RDS、RedShift などのサービスでKMSとの連携をサポート • https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/service-integration.html • Client-side Encryption • ユーザーアプリケーションでの暗号化してからデータを保存 • AWS Encryption SDKでKMSと容易に連携可能
  99. 99. 99安全なキー管理を実装する エンベロープ暗号化 • AWS Encryption SDKで用いられる方式 • AWS KMSやAWS CloudHSM等でマスターキーを管理 • 暗号化 • 保護対象のデータをデータキーで暗号化 • データキーをマスターキーで暗号化 • 複合 • 暗号化されたデータキーをマスターキーで複合 • 暗号化されたデータをデータキーで複合 Envelope Encryption https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption
  100. 100. 100人をデータから遠ざけるメカニズムを提供する 例:認証情報の管理 • Parameter Store / Secret Managerに保管し、アプリケーションが必要なタイ ミング(起動時など)に参照 • プログラムや設定ファイルへのハードコードによるリスクの緩和 • EC2インスタンスに対してParameter Store等へのアクセス権をIAM Roleで付 与することによるアクセス制御が可能
  101. 101. 101人をデータから遠ざけるメカニズムを提供する 例:データベースの接続情報をParameter Storeで管理 Parameter Storeへのアクセス権を定義 IAM Roleを介して Parameter Storeへのアクセス権を付与 インスタンスメタデータから認証情報を取得して Parameter Storeから接続情報を読み取り
  102. 102. 102伝送中のデータをどのように保護していますか?  伝送中のデータの保護に関する要件を定義する  安全な鍵および証明書管理を実装する  伝送中に暗号化を適用する  データ漏洩の検出を自動化する  ネットワーク通信を認証する
  103. 103. 103安全な鍵および証明書管理を実装する Certification Managerによる証明書管理 • 無償でサーバー証明書を発行 / 管理 • ただし、CloudFront / ELB / API Gatewayとの連携が前提 (EC2インスタンスに直接展開することはできない) • EV証明書は別途調達してインポートする必要あり • Private CAは有償
  104. 104. 104伝送中に暗号化を適用する あらかじめ作成 / インポートした証明書を選択するだけ
  105. 105. 105伝送中に暗号化を適用する HTTPSリスナーへのリダイレクト
  106. 106. 106伝送中に暗号化を適用する より安全な暗号化プロトコルの利用 • 「Application Load Balancer および 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.”
  107. 107. 107伝送中に暗号化を適用する AWS Site-to-Site VPN • IPsecをサポート
  108. 108. 108ネットワーク通信を認証する インターネット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
  109. 109. 109インシデントレスポンス SEC 11. セキュリティインシデントにどのように対応していますか?
  110. 110. 110セキュリティインシデントにどのように対応していますか?  重要な人員と外部リソースを特定する  ツールを特定する  インシデント対応計画を策定する  封じ込め機能を自動化する  フォレンジック機能を確認する  アクセスを事前準備する  ツールを事前デプロイする  ゲームデーを実施する
  111. 111. 111インシデント対応計画を策定する もしセキュリティイベントが起こったら・・・ • イベントの検知 / 外部からの通報 • 現状調査 • 責任者へのエスカレーション • 証拠の保全 / 問題の緩和 (侵害されたリソースの隔離、サービスの停止、認証情報の無効化、など) • 利用者など利害関係者への報告・広報 • サービスの原状回復、暫定対応 • 根本原因調査および対策 • 被害の補償
  112. 112. 112重要な人員と外部リソースを特定する ずべて自分たちだけで対応できますか? • 証拠の保全やそれを利用した根本原因の調査 • 外部の専門家へ依頼 • 利害関係者への報告 • 経営者や広報との調整 • 被害の補償 • 弁護士へ対応を委任 • 保険会社へ保険金の請求
  113. 113. 113ツールを特定する 自分たちでできることは? • ログの収集、分析 • 各種ログの収集と分析 • イベントの検知 • Guard Duty / Shield Anvanced / WAF 等だけでなく、Abuse Reportも確認 • リソースの隔離 • Network ACL・Security Groupなどで隔離する手順を予め確立 • メモリ上の情報を保全することも重要 (停止させずにサービスへの影響を排除することも重要) • 事前準備内容の評価
  114. 114. 114ゲームデーを実施する ゲームデーとは? • AWS環境が与えられる • そこに攻撃や障害など様々なイベントが発生 • 環境を維持することでポイントが貰えるので、チームでポイントを競う • 詳しくはこちら • 「AWS GameDayに初参加してみた【AWS GameDay Microservices Madness@AWS Loft Tokyo】」 • https://dev.classmethod.jp/etc/aws-gameday-microservices/
  115. 115. 115 まとめ
  116. 116. 116まとめ 体系的な手法で現状と課題を明確化 • Security外の柱でも評価してみましょう ビジネス要件を踏まえて優先度を設定 • 投資できる費用や優先すべき課題はビジネスによって異なる • ビジネス環境自体も変化する 継続的な評価と改善 • 定期的にレビューし、AWSのアップデートや脅威のトレンドを踏まえた改善を
  117. 117. 117

×