30歳になり新しいことを始めようと思い、今まで避け気味だったアウトプットに取り組み始めました。
拙い文かと思いますが、どうぞよろしくお願いします。
はじめに
※AWSのマルチアカウントと、関連サービスの詳細な説明は省略します
Supershipで取り組んでいるAWSのセキュリティ施策について紹介します。
AWS Control Towerと AWS Organizationsを導入し、マルチアカウントな統制管理を行っています。
ガードレール
AWSのセキュリティ・ガバナンスの統制について、ガードレールという考え方があります。
ガードレールは大きく2つの考え方で構成されています。
- あらかじめセキュリティ上問題のある操作を定義し、その操作を禁止すること（予防的統制）
- リスクがある構成、脅威などを検知・通知すること（発見的統制）
弊社ではガードレール型のセキュリティ対策を採用しています。
今回は発見的統制について記載します。
AWS Security Hub
AWSの定めるベストプラクティスに違反していないかなど、セキュリティ上問題がある設定などを検知することができます。
セキュリティアラートの集約を行うことも可能です。
Amazon GuardDuty
AWSアカウント上をモニタリングし、セキュリティイベントや脅威を検出します。
統制
AWSのベストプラクティスでは、Organizations管理アカウントから、セキュリティを管理する専用アカウント（委任アカウント）を作成することがベストプラクティスとなっています。
ベストプラクティスに従い、委任アカウントから各アカウントのSeucurity Hub、 GuardDutyの情報を集約・管理しています。
どこから対応するのか
Seucrity HubやGuardDutyも、内容に応じて重要度が割り当てられています。
重要度が高いほどセキュリティリスクが高いものです。
そのため、まずは重要度が最も高いもの（Critical）から対応することをオススメします。
どのように対応するのか
※統制を行うセキュリティ担当者が主担当として取り組む場合を仮定しています
Security HubやGuardDutyはAWSのベストプラクティスに準じてチェックを行いますが、システム特性上避けることができない検出がある場合があります。
それぞれの検出結果に対して、そのアカウントで構築されているサービス・システムの内容・特性を理解していないと判断することは不可能です。
そのような判断にはサービス・システムの理解が必須です。
統制を行うセキュリティ担当者のみでは対応できません。セキュリティ担当者がすべてのシステムを詳細まで把握することは困難です。
したがって、統制を行う管理者はアカウント利用者と密なコミュニケーションが必要です。
検出結果のトリアージなどをアカウント利用側のエンジニアと一緒に取り組む形が理想であると考えています。
システム特性上避けることができない例
- 特定のEC2インスタンスを外部に公開する必要がある
- 特定のS3バケットを外部に公開している
通知
発見的統制は、セキュリティアラートに気づく必要があります。
つまり、なんらかの形で通知する必要があります。
通知をしなければ、セキュリティ担当者が毎日AWSコンソールを開いて異常が発生しているか確認することになります。
運用の負荷を軽減するには、通知の仕組み化が必要です。
通知の仕組みについては、次回の記事にて記載予定です。
おわりに
セキュリティ対応というのは成果が目に見えにくく、取り組むモチベーションが上がりにくいです。
しかし、実際にインシデントが発生してからでは手遅れになります。
セキュリティ担当者もアカウント利用者も双方がジブンゴトとしてセキュリティに取り組むことが大事だと、記事にして改めて感じました。
参考
宣伝
Supershipでは情報システム担当/セキュリティエンジニアを絶賛募集しております。
興味がある方はSupership株式会社 採用サイトよりご確認ください。