「【招待制】今日から始められる AWS セキュリティサービス」に参加してきたメモ

# AWS セキュリティーワークショップ
- リスク可視化と分析による *継続的セキュリティ* の実践
- 登壇者：桐山隼人さん
- 著書：[すべてわかるセキュリティ大全](https://www.amazon.co.jp/%E3%81%99%E3%81%B9%E3%81%A6%E3%82%8F%E3%81%8B%E3%82%8B%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E5%A4%A7%E5%85%A82018-%E6%97%A5%E7%B5%8CBP%E3%83%A0%E3%83%83%E3%82%AF-ITpro/dp/4822259528/ref=asc_df_4822259528/?tag=jpgo-22&linkCode=df0&hvadid=295704876452&hvpos=1o1&hvnetw=g&hvrand=2164698928773520177&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1028853&hvtargid=pla-529465462497&psc=1&th=1&psc=1), [IoTビジネスとセキュリティを3段階と4要素で理解する](https://tech.nikkeibp.co.jp/it/atcl/column/17/052900219/053000005/)

## セッションの目的
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に相談してね！
- ワークショップや資料があるので勉強してね！

---

# ワークショップ内容
https://scaling-threat-detection.awssecworkshops.jp/