More Related Content Similar to AWSのセキュリティを考える!「AWS Well-Architected Tool」活用術セミナー セキュリティの柱を解説 Similar to AWSのセキュリティを考える!「AWS Well-Architected Tool」活用術セミナー セキュリティの柱を解説 (20) More from Nobuhiro Nakayama More from Nobuhiro Nakayama (20) AWSのセキュリティを考える!「AWS Well-Architected Tool」活用術セミナー セキュリティの柱を解説9. 9(セキュリティに関する)設計原則
• 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(セキュリティイベントに備える)
19. 19ベストプラクティス
• Identity and Access Management(認証・認可)
• Detective Controls(発見的統制)
• Infrastructure Protection(インフラストラクチャの保護)
• Data Protection(データの保護)
• Incident Response(インシデントレスポンス)
20. 20ベストプラクティス
• Identity and Access Management(認証・認可)
• Detective Controls(発見的統制)
• Infrastructure Protection(インフラストラクチャの保護)
• Data Protection(データの保護)
• Incident Response(インシデントレスポンス)
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 Control Policy (AWS Organizations)
• Organizationsで集中管理されたAWSアカウントをグループ化、行使できる権限を制御
• IAM Tagによるアクセス制御
• Principal(IAM UserやIAM Role)に付与したタグに基づいたアクセス制御
• CloudFormation StackSet / ControlTower
• 複数のアカウント・リージョンにAWSリソースをプロビジョニング可能
• 例:IAM Role / Config / GuardDuty などを一括でプロビジョニング / 有効化
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)
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 and Access Management(認証・認可)
• Detective Controls(発見的統制)
• Infrastructure Protection(インフラストラクチャの保護)
• Data Protection(データの保護)
• Incident Response(インシデントレスポンス)
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 システムレベルオブジェクトの作成および削除
• 悪意のある行為を識別・追跡するための情報
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)
• 後述する分析を想定して保存先を選択
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.
(補足要件を通常要件へ移行)
72. 72ベストプラクティス
• Identity and Access Management(認証・認可)
• Detective Controls(発見的統制)
• Infrastructure Protection(インフラストラクチャの保護)
• Data Protection(データの保護)
• Incident Response(インシデントレスポンス)
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等のコンプライアンス要件を満たしているかを評価
80. 80検査および保護を実装する
WAFによるWebアプリケーションの保護
• AWS WAF Managed 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(ホスト型)
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/
89. 89ベストプラクティス
• Identity and Access Management(認証・認可)
• Detective Controls(発見的統制)
• Infrastructure Protection(インフラストラクチャの保護)
• Data Protection(データの保護)
• Incident Response(インシデントレスポンス)
95. 95識別および分類を実装する
Amazon Macieによるデータ管理
• データの検出と分類(S3をサポート)
• データのアクティビティを監視 / 不審なアクティビティ発生時にアラート
• データの可視化(分類、アクティビティ)
分類手法
• コンテンツタイプ / ファイル拡張子 / テーマ / 正規表現 / 個人情報(PII) /
SVMベースの分類
• 「Amazon Macie でデータを分類する」
• https://docs.aws.amazon.com/ja_jp/macie/latest/userguide/macie-classify-data.html
99. 99保管中のデータの管理と保護に関する要件を定義する
例:PCI DSSにおけるデータ保護要件(の一部)
• 要件 3: 保存されるカード会員データを保護する
• 3.4 以下の手法を使用して、すべての保存場所で PAN を少なくとも読み取り不能にする(ポー
タブルデジタルメディア、バックアップメディア、ログを含む)。
• (中略)
• 関連する鍵管理プロセスおよび手順 を伴う、強力な暗号化
• 3.4.1 (ファイルまたは列レベルのデータベース暗号化ではなく)ディスク暗号化が使用され
る場合、論理アクセスはネイティブなオペレーティングシステムの認証およびアクセス制御メ
カニズムとは別に管理する必要がある(ローカルユーザアカウントデータベースや一般的な
ネットワークログイン資格情報を使用しないなどの方法で)。復号鍵がユーザアカウントと関
連付けられていない。
100. 100安全なキー管理を実装する
AWS KMS
• 暗号鍵の作成、管理、運用のためのサービス
• エンベロープ暗号化をサポート(後述)
• キーポリシーによるアクセス許可
• キーの利用権限や管理権限をキーポリシーとしてリソース側で制御できる
• 必要に応じて他のAWSアカウントに対して許可することも可能
• IAM Access Analyzerによる管理が可能
• 信頼ゾーン外(KMSリソースを持つAWSアカウント外)へのアクセス許可を検出
• 意図的な許可はアーカイブし、意図的ではないアクセス許可を発見 / 排除する
101. 101安全なキー管理を実装する
エンベロープ暗号化
• AWS Encryption SDKで用いられる方式
• AWS KMSやAWS CloudHSM等でマスターキーを管理(マスターキーはKMSから出ない)
• 暗号化
• 保護対象のデータをデータキーで暗号化
• データキーをマスターキーで暗号化
• 複合
• 暗号化されたデータキーをマスターキーで複合
• 暗号化されたデータをデータキーで複合
Envelope Encryption
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption
104. 104人をデータから遠ざけるメカニズムを提供する
例:認証情報 / 鍵の管理
• Parameter Store / Secret Managerに保管し、アプリケーションが必要なタイ
ミング(起動時など)に参照
• プログラムや設定ファイルへのハードコードによるリスクの緩和
• EC2インスタンスに対してParameter Store等へのアクセス権をIAM Roleで付
与することによるアクセス制御が可能
その他の例
• 監査証跡となる各種ログの改竄を防ぐためにダッシュボードやクエリのための
ツールを提供(生データに直接アクセスさせない)
• QuickSight / Athena など
111. 111伝送中に暗号化を適用する
より安全な暗号化プロトコルの利用
• 「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.”
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
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 and Access Management(認証・認可)
• Detective Controls(発見的統制)
• Infrastructure Protection(インフラストラクチャの保護)
• Data Protection(データの保護)
• Incident Response(インシデントレスポンス)
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/
123. 123封じ込め機能を自動化する
想定される封じ込め方法
• 例:Security GroupもしくはNACLによる遮断 / ELBからデタッチ
• 調査のために必要な経路のみを確保
• 他のリソースに与える影響に留意
• 想定可能な手順はスクリプトで自動化 など
• 根本原因調査のためのクリーンルーム(隔離されたVPC)
• 取得したフォレンジックディスクイメージ(AMI)を展開 / 詳細な調査
• CloudFormationなどで展開できるとスムーズ
• 【注意】インスタンスの停止は(少なくとも)証拠の保全後に実施
• ライブレスポンス / メモリ収集 / フォレンジックディスクイメージなど必要な措置を先に実施
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(セキュリティイベントの集約)
132. 132参考資料
NIST Special Publication 800-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/