この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは！AWSエンジニアのおつまみです！
みなさん！セキュリティ対策やってますか？
今回は先月（2023/2/10）に発売された「AWSではじめるクラウドセキュリティ」を紹介します。
既に弊社エンジニアにて書評されていますが、若手？エンジニアも素晴らしいと思ったこの1冊をぜひ紹介させて下さい！
他の方の書評はこちらです。
この本を読んだ目的
- セキュリティの重要性を再認識したい。
- セキュリティ対策として何をしていいかわからないお客様にAWSのセキュリティサービスを適切に案内できるようになりたい。
簡単に概要まとめ
第1部：クラウドとセキュリティの基本
1章：セキュリティとは何か？クラウドとは何か？
- セキュリティは守るものがあってはじめて必要とされる。
- 目的を意識してセキュリティサービスを活用する。
- クラウド利用により、セキュリティで守る範囲が大幅に削減される。
2章：セキュリティと責任共有モデル
- セキュリティ管理策の検討ステップ
- 何が期待されているか（Why・What） → 説明責任があり、アウトソーシングできない。
- どのように実現するか（How） → 実行責任があり、アウトソーシングできる。
- AWSが提供しているSLAを理解し、責任共有モデルを理解する。
3章：ガバナンスとセキュリティ要件
- ガバナンス
- 組織が健全な経営をできているための機能やプロセス。組織経営者はこれを理解し、説明責任をもっている必要がある。
- ガバナンス内には組織が法令やモラル、社会の期待に応えているかを把握するコンプライアンスが含まれている。
- セキュリティの3要素（機密性・完全性・可用性）の中でも、可用性を第一に考える。
- 可用性は提供するサービスの必要要件と重なる部分。
- 「何のためのサービスか？」「何のためにセキュリティ対策をやるのか？」を根幹に考える。
4章：セキュリティポリシーを作る
- 既にある既存フレームワーク（ISO,NISTなど）を組織に適するようカスタマイズする。
- セキュリティの原則は以下の通り。
- Need to know（必要な人のみに開示）
- Authentication and Authorization（認証・認可）
- Least Privilege（最小権限）
- Three Lines Defence（現場部門・監査部門・経営部門でのリスク管理のあり方）
- セキュリティポリシーの形骸化・陳腐化・先例主義を回避するためのアプローチは以下の通り。
- 原則中心（原則からは逸脱しない）
- アジャイル的（とりあえずやってみる）
- DevSecOps（共に考え、共創する）
- ガードレールにより業務を止めない
第1部の感想・印象に残ったところ
- 1章はエンジニアだけでなく、システム提供をしている全員が読んだほうが良い内容であった。また何度も読み返した方がいい。
- 「なぜセキュリティ対策をやるのか？」「何を守りたいのかは？」組織側の経営者による説明責任が必要。この部分はアウトソーシングできない部分である。
- ただお客様によっては、このWhyやWhatがそもそも何なのか分かっていない場合が大半である。そのため、ここはクラスメソッド側から説明する必要がある。例えばwhatは「機密情報」「個人情報」「送信データ」などが当たる。
- お客様から「セキュリティ対策したいです」と相談された際に、この部分をちゃんと説明できるようになる必要があると感じた。
- あくまでもクラスメソッドとしては「どのようにそれを実現するか」「どういったフレームワークがあるか」「他社ではこのような対策をしています」といった手段を提供することしかできない。そのため、できる限りお客様にも理解していただきたい。
第2部：AWSでセキュリティを実現する
5章：セキュリティポリシーを作る
- rootユーザーやアクセスキー発行時の注意など基礎的な権限管理について
6章 リスクの特定とセキュリティ管理策の決定
- CSF(サイバーセキュリティフレームワーク)における5つのセキュリティ機能は以下の通り。
- 識別（6章）
- 防御（7章）
- 検知（8章）
- 対応（9章）
- 復旧（10章）
- 6章では「識別」に関して、リスクを特定・分析・評価するまでの手法を解説している。
- システムの特性を理解しながら、リスクアセスメントでフレームワークを活用する。
- ベースラインアプローチ（汎用的）
- リスクベースアプローチ（システム特有）
- 資産ベース
- 攻撃シナリオベース
- リスクへの対応に紐づためにはリスク評価が必要だが、実態としてできていないシステムが多いのではないかと感じた。
7章 セキュリティ管理策の要となる防御
- 「防御」には「予防的統制」として、「権限管理」と「暗号化によるデータ保護」がある。
- 権限管理：IAM
- 暗号化によるデータ保護：KMS・ACM
- セキュリティへの意識を高めるためのトレーニングも「防御」に含まれる。
8章 セキュリティ検知の仕組み作り
- 完璧に実施できない「防御」を補完するために「検知」の仕組みづくりが必要である。
- 「検知」は外部・内部の脅威発生や異常の兆候を発見することである。
- 監視業務と分析業務によって実現できる。
9章 AWSで対応／復旧を始める
- インシデントレスポンスへの十分な「準備」が必要である。
- インシデントプロセルの整備を行い、プロセスをドキュメント化しておく。
- プロセスの流れは以下の通り。
- どんなことが発生したら（シナリオの定義）
- 何を（対応方法の定義）
- 誰がする（役割と責任の定義）
第2部の感想・印象に残ったところ
- CSF(サイバーセキュリティフレームワーク)における5つのセキュリティ機能別に異なる役割があるため、各々を理解して実施すべきと感じた。
- 何度も読み返した方がいい。（再喝）
第3部 AWSのセキュリティを試す
10章 代表的なセキュリティサービスの操作
- 割愛
11章 セキュリティ対応環境の構築、脅威検知／対応
- 割愛
特に印象に残った部分
セキュリティ責任共有モデル
- 本来やらないといけないことをAWSが代わりにやってくれるが、利用者自身で設計が必要な部分もある。クラウドだからなんでもやってくれるわけではないということを十分に理解する必要がある。
責任分解に基づくセキュリティ対応箇所の識別
- リスク評価できていないと、その後のリスク対応も検討できない！
- 面倒だけどやるべき！
さいごに
今回は「AWSではじめるクラウドセキュリティ」の概要を簡単にまとめてみました！ 本書を読んだ目的として、以下を挙げていました。
- セキュリティ対策として何をしていいかわからないお客様にAWSのセキュリティサービスを適切に案内できるようになりたい。
本書を読んで、セキュリティ対策をやりたいと言われたお客様に対して、いきなりAWSのセキュリティサービスを進めるのではなく、守るべき資産とその重要度を確認することが重要だと学びました。特に対策前のリスク評価が重要ですね。
セキュリティは奥が深いけど、改めて面白いなと感じました。
気になった方はぜひ本書を手に取ってみてください。
最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。
以上、おつまみ（＠AWS11077）でした！
0
