この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは韓です。 幕張メッセで開催されている AWS Summit Tokyo 2019 のセッションレポートをお届けします。
概要
登壇者:
- Amazon Web Services, Inc., Principal - Office of the CISO, Henrik Johansson
お客様のサービスがGDPR(欧州連合の一般データ保護規則)、PCI(Payment Card Industry Data Security Standard)、もしくはFSI(金融サービス業界)の規制対象ワークロードの要件を満たしているかよりも、お客様自身のアカウント内でどのサービスが稼働しているかをしっかり把握し、セキュリティの観点からサービス状況を把握する事こそ、全ての規制対象ワークロードにとって極めて重要と言えます。本セッションでは、お客様のチームや組織が、AWSクラウド環境上に構築した規制対象や機密性の高いワークロードの可視性をどのように高めていくかについて説明します。複数のリソースのログデータ、マシーンラーニングサービス、およびセキュリティのインシデントの原因を見分けることを手助けするためのマネージド型のセキュリティサービスのほかに、AWS GuardDutyといった悪意のある操作や不正な動作を識別するためのマネージド型のセキュリティサービスの使用方法についても説明します。
セッションレポート
責任共有モデル
AWSでのセキュリティを考える基礎となるもの。どの範囲に責任持たなければならないかを再確認。
- 顧客: クラウド内のセキュリティに責任をもつ
- AWS: クラウドのセキュリティに責任をもつ
これまでのセキュリティが非常に難しい理由
- 可視性の不足
- やったことは報告されて初めて気づく
- 自動化される割合の低さ
- 手動作業が多くリスクが高い
- また変更があったことが記録されないことがある
しかし現在では、クラウドのワークロードによってかつてないほどのセキュリティ体制の強化、最適化、および改善が可能 となっています。 既存のツールやルールの多くはクラウドでも利用できるし、利用できない場合でも代替ツールがあるケースが多い。
最も重要なセキュリティ要件は「可視性」
可視性 とは以下を明らかにすること：
- 何がおきているか
- 誰が何をできるか
例1) FWのコンフィグを変更できるのはだれか？
- レガシーシステムでは、調査や聞き取りをしたりと時間と労力がかかる
- AWSでは、コマンド1発で出力できる
例2) 全体の認識範囲外に潜んでいるものがある
- デスク下にある検証用サーバなど
- 一担当者しか知りえない場所にライセンス違反やセキュリティリスクがある場合がある
可視性とは認識
- 可視性とは全体像の把握である
- リソースの配置ではなくフローを押さえることが肝要
- 全体像を書いてデータがどう流れているかを話す必要がある
可視性を必要とする人は？
- 全員にとって必要
- 運用担当
- 開発担当
- セキュリティ担当
- コンプライアンス担当
可視性による可監査性の実現
- 可視性によって運用セキュリティロールにミクロレベルのリソースに関する詳細な情報をすぐに提供できる
- 可監査性により、統制及び証拠レベルのオンデマンドで繰り返し適用可能なレポートを得ることができる
可視性の拡張するためには？
可視性を高めなければならない箇所は至る所にあり、これらを全て明らかにしなければならない。
- プログラマがクレデンシャル情報をGITにコミットしないようにすること
- コンテナにパッケージが入らないように
- テスト環境へ自動PUBLISH、ステージングは手動
- etc.
また、可視性の拡張とは適切に情報を通知することであり、 Slack, Mail, Amazon Chime のような通知サービスと、キーとなる情報を抽出して送信する機能の実装の双方が必要となります。
可視性とは全体像の把握
- 隠れていたものを明らかにし不要なもの排除する
- 流れを把握しキチンと防御を行う
監査対応
人間の活動はとても優れていますが、一貫性を担保するのは非常に困難です。そのためにすべきことは以下が肝要。
「人をデータから隔離する」
AWS にはセキュリティを改善するための様々なサービスがあり、人が行っていた作業をセキュアに自動することでセキュリティを挙げることができることがで出来るとともにログによって追跡可能になる。
※ セキュアな自動化: 反復プロセスを自動的に作業がなされるようにすること。人が介入しないで実現できるのが肝。
- クラウドの統制
- AWS のサービスを用いてセキュリティを改善
- 全ての人を対象とする
- 規模に依らず実施する
- 責任共有モデルを理解し行動する
- クラウド自体はAWSがやる
- クラウド内は自身で保護する
- 優れた可視性と統制による安全な拡張
- データが保存される場所とデータにアクセス可能な人を管理
- リソースへの適切なアクセス権を保つため、よりきめ細やかくIDをアクセスを管理
- セキュリティ自動化と継続的な監視活動によってリスクを軽減
- AWSサービスを活用する
AWS における対策
ここからはAWSのセキュリティ関連サービスについて述べられた。
AWSはプライバシーとデータセキュリティに最も配慮している
- AWSはデータを勝手に複製したり移動しない
- どのリージョンに何のデータを置くのは利用者が決める
- リージョンを跨いでデータが勝手にコピー・移動されることもない
- 各国の個人情報保護法への準拠
- リージョンごとにその国の法律に準拠している
- 様々なセキュリティサービスがある
- セキュリティ分類に無いサービスもセキュリティに役立つサービスは多い 例) SystemsManager
可視性を高め統制による安全を確保するには
- データが保存される場所とデータにアクセス可能な人を管理する
- リソースの適切なアクセスを保つためきめ細やかにIDとアクセスを管理
- セキュリティ自動化と継続的な監視活動を実施
- AWSサービスを活用し、既存ワークロードのサポート・運用自動化・コンプライアンスの簡素化を実現する
しかし課題を発見できても受けとる体制が必要となり、それは利用者自身が用意する必要がある。
AWSセキュリティサービスの概要
- 識別
- システムに起きうることと影響範囲を知る
- AWS SystemsManager, AWS Config
- 保護
- 起きうることへの対策
- AWS IoT Device Defender, AWS Key Management Service, AWS Identity and- Access Management, AWS Single Sign On, AWS Firewall Manager, AWS Secrets Manager, AWS Shield, AWS WAF, Amazon VPC
- 検出
- セキュリティリスクが発生したことを知る
- Amazon Inspector, Amazon Macie, Amazon GuardDuty, AWS Security Hub
- 応答:自動化
- 自動応答可能なリスクに対しては自動化で対応することができる
- Amazon CloudWatch, AWS Lambda
- 応答:調査
- 予見しえないリスクが発生した際はどのような事が起きているかを調べる
- Amazon CloudWatch, AWS CloudTrail
- 復旧
- 対応が難しい場合はリスクが発生しているインスタンスを隔離するなどの対応をとり、Snapshotやアーカイブから再構築を行いシステムを復旧する
- Snapshot, Archive
知っておくべきAWSのセキュリティサービス
ASWSSecurity HUB
- CIS AWS Foundations Benchmark に基づいている
- オープンなセキュリティグループが無いか等といったセキュリティリスクを検出できる
- ダッシュボードがあり検出結果の確認ができる
- インシデントがあった場合に、優先順位をつけて対応するかの判断基準になる
- 現在、東京を含む15リージョンで提供中
AWS Security Hub のインサイト
- セキュリティ検出結果は、優先順位付けのため関連付け・グループ化される
- 20以上の事前構築済みのインサイトがAWSとAWSパートナーから提供されている
- 独自のインサイトを作成できる
- ダッシュボードでは検出結果の一覧と詳細を確認できる
検出できる例:
- セキュリティパッチが不足している EC2 インスタンス
- 認証情報が保存されている S3 バケット
- 外部からアクセス可能で読み書き権限が設定された S3 バケット
セキュリティ対応の肝
- 可視性が最も重要
- リスクを顕在化することができる
- 可視化によって自動化が進む
- 自動化はミスを防ぐ
- 多くのインシデントは手動作業によって起きている
- 自動化で「人をデータから離す」ことでリスク回避
まとめ
セキュリティに関する基本的な考え方に関するセッションで、詳細で具体的な対策というよりも、どのように取り組むかに焦点を置いた内容でした。 皆さんもこのセッションを参考に、可視性が高く安全なシステムを目指していきましょう。
4
