AWS セキュリティーワークショップ
- リスク可視化と分析による 継続的セキュリティ の実践
- 登壇者：桐山隼人さん
- 著書：すべてわかるセキュリティ大全, IoTビジネスとセキュリティを3段階と4要素で理解する
セッションの目的
AWS環境においてのセキュリティって。。。
- まず何からはじめたらいいのか
- どこまでやったらいいのか
「継続的セキュリティ(CS)」
定義
- 人によって定義はまちまち
- DevOps.comより抜粋
- セキュリティにはプラットフォームが必要でAPIによって呼び出す
- 自動化で実施していくもの
- 統合インテグレーションと言われるものが必要
やる意味
- 環境変化適応
- セキュリティ対策は実施した瞬間から危殆化する
- スピード
- セキュリティ侵害は攻撃側のほうがはやい
- 攻撃は自動化してどんどん新しい攻撃手法を取り入れていく
- コスト最適化
- リスクベースのアプローチで考える
- 何が一番重要で守らなきゃいけない？を考える必要がある
- リスクは瞬間で変わっていく
セキュリティリスク
セキュリティリスクの方程式
- 驚異
- どういうリスクが企業にあるか？どういう企業はリスクが高いのかを考える
- 有名であればあるほど狙ってやろうという気持ちが高まる、など
- 脆弱性
- 企業の中に存在するもの
- セキュリティホールや設定ミスとか
- 心理的要素を突く攻撃もある（人事に対してや、プレッシャーかかってる人へのメールとか）
- 情報資産
- 企業が持ってるデータの情報資産の価値が高ければ高いほどやばい
- 企業によって持ってるデータが違うので重要度がぜんぜん違う
- 医療機関のほうが金融機関よりも重要、みたいな
分析と可視化
- リスク分析
- 驚異分析 (AWS GuardDuty)
- 脆弱性分析 (AWS Inspector)
- 情報資産分析 (AWS Macie) ↑をやることがセキュリティ対策
継続的監視と驚異検知
-
機械学習を用いたクラウドネイティブな驚異検知サービス
- 驚異を検知してくれる = GuardDuty
- 検知方法：クエリのログやネットワークログ、API操作ログを使って驚異を検知する
-
プラットフォーム脆弱性分析
- API連携によって開発運用プロセスにリスク評価を統合
- やってくれること：こういうセキュリティ設定したほうがいいですよ、とかも評価してくれる
- Inspectorのルールパッケージ
- ホスト評価のルール(CVEに基づく一般的な脆弱性、COS OSSCB, ベストプラクティス、とか4軸)
- ネットワーク到達可能性のルール ←NEW!!
- 自分で意図したネットワーク設計になっているか
- インターネット出てる？
- 意図したところだけ使われてる？
- PCI DSSの要件満たしてる？
- これを知るためにInspectorのルール評価が使える
- やってること
- 自動推論による評価
- Logic Specification + Network Snapshot + query = Result
- パケットレスポートスキャン↑をやっている
- 自分で意図したネットワーク設計になっているか
-
事業価値のある（重要データ）データを保護
- 認証情報、知的財産、個人情報とかを保護
- Macieがスキャンして、監視できる
一個一個の画面にはいるのめんどくない？
ｰ> Security Hub というサービスがあります！
リスク分析ダッシュボード - Security Hub
- AWS環境のセキュリティコンプライアンス状態を可視化できる
- 一元的にみれるよ！
まずここからその１
- まずは始めるなら
- GurardDutyを全リージョンで有効化
- InspectorでEC2インスタンスを評価
- エージェントレスもありますよ
- MacieでS3にある重要データの棚卸し
- サポートリージョンは北バージニアとオレゴンのみ
- Securitie Hubでデータ集約して可視化
コンプライアンスルール
リスクベースアプローチによる優先順位づけ
- リスクベースアプローチを保管する考え方が大事
- ベースラインアプローチ
- 業界ルール
- などこれは守らないといけないよね、みたいなシステム外の観点のこと
- = コンプライアンスルール → 「Compliance Check + AWS Config」 で管理できる
※ AWS Config = 構成変更を記録してくれるサービス
まずここからその２
- Configで全リソースの設定変更履歴の管理を開始
- Security HubでCompliance Standardsを有効化する
ガバナンス
- AWS Organizations
マルチアカウント
- 増えていった時、一個一個どうやって管理すればいいのか
- Landing Zoneを使おう！
- ここに着地して貰えればいいよ、的なニュアンスを含めたもの
- アカウント統制をしたい時、こういうルールだけ守ってね、の枠を定義できるもの
- ベストプラクティスをまとめたまとめ集
- 目的が違うアカウントを分けておいたほうがいい
- ログ管理とセキュリティアカウント、など
- 日頃の振る舞いが違うやつ
- 混ぜるとノイズが入るので、新しい技術が入れづらい = 入れていいの？のリスクが発生する
- だからアカウントは分けておきましょう
- アカウントのセキュリティイベントを集めて通知する
- 通知はアカウントごとでSNSトピックを生成する
- 集約はSecurity Hubで
まずはここからその３
- セキュリティアカウントを作る
- Securitie Hub上で監視対象のメンバーアカウントを追加
- Securitie HubのカスタムアクションでFindingsの追加
次のステップ...
- わからない人はAWSのSAに相談してね！
- ワークショップや資料があるので勉強してね！