概要
- 現在の業務で実施しているAWSのセキュリティに関係する部分について備忘の意味も含めてまとめていきます
- あくまで備忘的なまとめです
SecurityHubについて
- AWS環境でのセキュリティ情報を一元管理できる。サービス対象は以下のサービスなどがある詳細はこちら
- Amazon GuardDuty
- Amazon Inspector
- Amazon Macie
- AWS Firewall Manager
- IAM Access Analyzer
- AWS Config
- AWS Trusted Advisorと連携し運用の評価を行うことができます。またTrusted Advisor自体の警告もSecurityHubから確認することができます
SecurityHubで使用しているセキュリティ基準
- 代表的なセキュリティ基準は以下のものがあります(重複しているものがあります)
- AWS Foundational Security Best Practices v1.0.0 (FSBP) 標準
- S3 バケットのパブリックアクセスが制限されているか、VPCフローログが有効かされているか？などをチェック
- CIS AWS Foundations Benchmark
- IAM ポリシーが適切に設定されているか、多要素認証（MFA）が有効化されているかなどの基本的な要素のチェック
- 詳細はこちら
- NIST SP 800-53 Rev. 5
- ロードバランサーに関連付けられた Auto Scaling グループは ELB ヘルスチェックを使用する必要があるなどをチェック
- 詳細はこちら
- Security Hub の PCI DSS v3.2.1
- クレジットカードおよびデビットカードの情報を安全に処理するためのルール
- 詳細はこちら
- AWS リソースタグ付け標準
- AWS Foundational Security Best Practices v1.0.0 (FSBP) 標準
どういった時に使用するか？
- ControlTowerで複数のAWSアカウントを管理する際に管理部門で管理したい場合また各アカウントでも注意をしてほしいときに利用する。
- 合わせてOrganizationのSCPで制約を掛けることも有効
- SecurityHubを導入するときには以下のどちらを行って統制をかけるか？を検討をする必要がある
- ガイドラインを制定し準拠することをルール
- ガイドラインと最低限やってはいけないことを定めたガードレールを合わせる
- コンプライアンス、柔軟性、コストの観点で比較します
コンプライアンスの観点での比較
- ガイドラインのみの場合
- 管理対象のアカウントの利用者が共通の認識を持っている場合には適用できる
- 人数が多い場合や利用者間で知識の差が顕著にある場合など認識にずれが発生しそうな場合は不向き
- ガードレールと合わせる場合
- システムとして制約をかけるため知識の差などがあってもルールから外れた場合は気づくことができる
柔軟性の観点での比較
- ガイドラインのみの場合
- システムとしての制限がないため柔軟な対応が可能となる
- ガードレールと合わせる場合
- システムとして制約をかけてしまうため柔軟性は損なわれる
コストの観点での比較
- ガイドラインのみの場合
- ほかの観点と制約はかからないが、誤った設定で余分なコストがかかるリスクがある
- ガードレールと合わせる場合
- 余分にコストがかかるようなケースは事前に制限できる
通知について
- 通知にはメールやslackなどを使い通知を行うことになるが、通知を有効にする前に事前に対応できるエラーは対応してから通知をonにしている。
- 特に最初から有効化していない場合は通知が埋もれてしまうこと避けるために事前に対応している。
業務で使用時の考え
- 利用者の知識に応じてどこまで統制を取るか？を事前に決めてガイドラインのみで済ませるかガードレールをどこまで厳密にするかを検討することになる。(業務ではガードレールもある程度指定する方針)
- あくまでこれは一例なので使う際の参考程度になればと思います