Security-JAWS 第15回レポート #secjaws #secjaws15 #jawsug

Security JAWS 第15回のレポートです。いつもどおり幅広いジャンルの話がありました！まずIAM本を買いましょう←

#JAWS-UG

#レポート

#セキュリティ

#AWS

臼田佳祐

2019.11.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

Security JAWS 第15回が開催されましたのでレポート致します。

Security-JAWS 【第15回】勉強会 2019年11月11日(月) - Security-JAWS | Doorkeeper

レポート

Session1: アマゾンウェブサービスジャパン株式会社大村幸敬さん「Management & Governance on AWS こんなことできます」

AWSのManagement & Governanceサービス
- 参考: Management とGovernance
  - ガバナンスは方向付けしたりその評価など
  - マネジメントはその実行のための計画や構築など
    - マネジメントが実行部分を担う
    - ガバナンスの一部の役割を担う
  - ITガバナンスはステークホルダーへの説明責任を持つ
  - ITマネジメントは経営への説明責任を持つ
- ガバナンスとアジリティ
  - 一般にはトレードオフになりやすい
  - AWSでは両方損なわないでできる
- AWSのサービス
  - 様々なメリット
    - スケールやカバレッジ、経験など
- サービスの領域
  - 有効化
    - アジリティとがなバンスを有効化
    - 継続的に増加するAWSサービスを管理
    - 環境のセットアップ
    - コントロールの有効化
    - アカウントとポリシーの管理
    - コストコントロールの確率
    - これらを継続的に改善
    - サービス
      - Control Tower
      - Organizations
      - Budgets
      - License Manager
      - Marketplace
      - Well-Architected Tool
  - プロビジョニング
    - 当生活事前承認済みのITサービスのみデプロイできるようにする
    - DevOpsチームで活用したり
    - ビジネスユーザが固まったものをつかったり
    - サービス
      - CloudFormation
      - OpsWorks
      - Service Catalog
      - Marketplace
  - オペレーション
    - 監視
    - 監査
    - 対応
    - 最適化
    - サービス
      - CloudWatch
      - CloudTrail
      - Config
      - Systems Manager
      - Trusted Advisor
      - Cost Explorer
  - これらのサービス群がマネジメント・ガバナンスサービス
3rdパーティとオープンソース・ソリューションも活用するといい
ユースケース
- 必須ソフトウェア未導入の検知
  - QuickSightで各サーバにインストールされているパッケージの一覧表示
  - AWSのサービスを組み合わせて実現
    - SSM Inventoryでソフトウェア情報を収集
    - S3 -> Athena -> QuickSightで可視化
  - オンプレミスサーバも同じ仕組みで
  - Config Rulesを利用して導入状況を監視
    - CloudWatch EventsからLambda等でアクション
    - 自動修復アクションなど実施
  - 違反したら通知、サーバ停止、インストールなどの対処
- AWS環境のコンプライアンスチェック
  - AWS Config / Config Rules
    - 変更履歴、構成変更を管理
    - Config Rulesが2019/8より大幅な値引きがされた
    - Control Towerのアカウントガードレール
      - 中身はConfig RulesなのでControl Towerを使わなくてもガードレールは作れる！
    - カスタムルールで自分なりのルールも作れる！
- リモートアクセスの事前許可と事後確認
  - サーバへのリモートアクセス(踏み台ホスト)
    - 踏み台でやりたいこと
      - 接続の記録
      - 操作の記録
      - 接続元の限定
      - 踏み台の追加認証
    - でもSSHポート等を開けたりしないといけない
  - Session Managerを利用する
    - 踏み台が要らなくなる
    - SSHのポートを開けなくていい
    - 認証はIAMで
    - 認可もIAMで
    - 接続の記録や操作の記録はSession Managerでできる
  - 事前の申請に基づいてIAM Policyを作って管理
  - 参考: Session Managerトンネリングによる接続
    - RDPはトンネリングで対応できる
    - しかし操作記録は取れないので注意
  - 参考: EC2 Instance Connectによる一時認証
    - 一時的な認証情報を渡す機能
- ログ/メトリクスの調査
  - AWS Config の高度なクエリ
    - SQLでチェックできる
    - サンプルクエリもある
  - CloudWatch Logs Insight
    - 高速で強力
  - CloudWatch Cross-Account / Region Dashboard
    - クロスアカウントでまとめて見れる
最後
- 使っていないEBSを削除するブログを公開したよ
- 使用されていないAmazon EBSボリュームを削除してAWSのコストをコントロールする | Amazon Web Services ブログ

感想

AWSのサービス群だけでもいろんなことが実現できるのでぜひコンプライアンス/ガバナンスを利かせるために活用していきたいですね！

SSMはネ申！

Session2: 株式会社ZWEISPACE JAPAN 亀田勇人さん「ブロックチェーンアプリ・オン・AWS セキュリティ編 ---- ステーブルコイン・遺言スマートコントラクト・地震情報 ----」

ビザンチン51%
- システムが乗っ取られちゃうやつ
51%アタックはどれ？
- コインチェック
- イーサリウム・DAO
- モナコイン
正解はモナコイン
- DAOはスマートコントラクトの脆弱性
ビットコインのハッシュ計算力は？
- 100,000,000,000,000,000,000回/秒
- テラハッシュ/s
半減期(Bitcoin Halving)
- ブロックサイズにCapをしているからなかなか取引できないとなっている
- 10分で2Gのブロックサイズになっている
Bitcoin residence
- 1Bitcoinで1ヶ月東京で暮らせる
不動産向けのBlockChainの仕組みをいろいろ作っている
遺言の信託のSmartContract
- 何かあったら可及的速やかに配分される仕組み
建物にセンサーを付けて自身に関する情報を収集
- AWSにあげてblockchainで管理
- いろんなBlockchainに管理
- Publicのchainにも書く
- 誰かがハッキングしたりしたら終わるのでDBだけに頼らない
- 地震のデータは記録だけすればいいのでblockchain向き
- Blockchainは処理能力がすごくあるからそっちに任せたほうがいい
- DBで自前で管理するより圧倒的に安心

感想

Blockchainのスケールのでかい話でした。

書き込んで終わりのデータならDBよりもBlokchainがいい場合があるというのは面白い話ですね！

Session3: NRIネットコム株式会社佐々木拓郎さん「IAMの設計を言語化する」

本書いてます
- https://booth.pm/ja/items/1563844
- 編集記: 私も買いましたが非常に良書です。オススメ
AWSとセキュリティ
- いろいろやることが多くてややこしいと思ったことはありませんか？
- 全体像を把握するためにざっくり分類
- 4つの軸で考える
- AWS内に構築したネットワークとサーバのセキュリティ
  - 責任共有モデルの上側
  - 考え方はオンプレと大きく違わないが、設定の仕方はAWSも流儀に従う必要がある
- AWSのサービス群の設計設定
  - いわゆるマネージドサービス
  - ユーザ自身でカバーする範囲は少ないがサービス毎に特性を理解する必要がある
  - まずは使うものだけ覚えればいい
- AWS操作に関する権限(IAM)
  - AWSのセキュリティの中核の1つ
  - どんなにネットワークやサーバのセキュリティ設定をしていても、AWSを直接操作されると穴が開けられる
  - 今日のテーマはこれ！
- セキュリティを維持管理
  - AWS独自の部分
  - 利用しなくてもシステムをセキュアな状態を維持できるが、うまく活用すると自力でやるより100倍楽になる
  - 11/23のJAWS-UG 千葉支部でこのテーマで話します
  - https://jawsug-chiba.doorkeeper.jp/events/99430
IAMの設計を言語化する
- 守るべき基本方針は2つだけ
  - 認証情報を盗まれないようにする運用設計
    - アクセスキーではなくロール利用
    - git-secretsの利用
  - 盗まれても被害を最小限にする権限設計
    - MFA必須化
    - 最小権限の設計
IAMポリシーのデザインパターン
- IAMポイリシーのデザインパターン
  - ホワイトリスト
  - ブラックリスト
  - ハイブリット
  - (佐々木さんが勝手に命名
- ホワイトリスト
  - 許可する権限のみ付与していくパターン
    - EC2やS3などサービス単位やさらに細かくアクション単位で付与
    - AWS管理ポリシーも近いけど少し粗い
  - メリット
    - 最小権限が設計できる
    - 理解していれば一番セキュア
  - デメリット
    - 設計が進まないと設定できない
    - 管理負荷が高い
      - 新しいサービスへの追尾が大変
- ブラックリスト
  - 拒否を追加していくパターン
  - 許可してはいけない権限を剥奪していく
    - 管理者からユーザ管理だけ奪うなど
  - メリット
    - 設計が最小限にできる
    - 自由度が高い
  - デメリット
    - 予期せぬサービスが突然使えるようになるリスクがある
- ハイブリット
  - ホワイトリストとブラックリストの組み合わせ
  - 権限を付与した上で禁止したい権限を削る
  - メリット
    - AWS管理ポリシーが使いやすい
    - 自由度が高く設計が楽
  - デメリット
    - あまりない
    - 重ねがけ方法は注意
IAMグループのデザインパターン
- 複数グループに所属
  - ユーザが複数のグループに所属することを前提に権限設計
    - 階層構造を作りやすい
- グループ内に複数のポリシー
  - ユーザが1つのグループに属することを前提に権限設定
  - ユーザからみるとシンプル
  - 見通しがいい
- どちらがいいかはない
- 環境に応じて使い分け
パターンの原則を踏まえた上で具体的な設定に落とし込む
- MFA必須化とIP制限
  - 共通ポリシーで検討するもの2つ
    - 編集記: 詳細のポリシーは本を見て
- 管理者権限の設計
  - Admin権限を付与した上で制限を加える
  - IP制限をなくすための管理者用ロール
  - ログイン時は参照権限のみを使うといい
    - オペミス防止
- ネットワーク管理者の設計
  - 職務機能のAWS管理ポリシーを活用する
- 開発者の設計
  - 一番悩ましい
  - 今はロールを作ることが多いので開発者にIAMロール作成権限を与えないといけなくなる
豆知識
- スイッチロールの注意点
  - Principalを絞らないと全ユーザがスイッチできる
  - rootじゃなくてuser/ユーザ名で指定
- 最小権限のジレンマ
  - ベストプラクティスだけど…
    - 高度な知識が必要
    - 新規サービス追加に弱い
    - Admin持ってないと最小権限を追求できない
まとめ
- 言語化すると何となくわかる
- 自分の環境の設計を言語化するといい

感想

IAMはセキュリティの根幹の1つなのでぜひしっかり押さえておきたいですね。

まずは本を買いましょう←

まずは最低限のMFAや制限から！

Session4: パロアルトネットワークス株式会社中村弘毅さん + ゲスト「これから始めるのは、TGW or クラウド態勢管理？」

AWSとの関わり
- 仮想版次世代Firewall
- CSPM - Prisma Cloud
- Twistlock
TGWのネットワーク・セキュリティ
- VM-Seriesデザインモデルは？
  - 色々ある
  - 今回はTransit Gatewayモデルの話メイン
- アウトバウンド・イーストウェスト
  - アメリカでは使われるようになっている
- Transit VPCモデル
- TGWで検討すべきこと
  - インバウンド or アウトバウンド
  - VPCインサーション or VPNアタッチメント
    - VPNアタッチメントはダイナミックルーティングできる
  - 使い分けていくのがベストプラクティス
- TGWインバウンドトラフィック
  - VPCアタッチメント
- TGWアウトバウンドトラフィック
  - マルチで繋ぐ場合にはVPCアタッチメントしつつVPNアタッチする
  - 経路をなくさないように
  - アメリカだとBGP回す
- TGW VM-Series + Aviatrix連携するとやりやすい
  - 日本だと提供している代理店はない
- AWSリファレンスアーキテクチャガイドがある
クラウドの態勢管理
- クラウドセキュリティ分析サービスをやっている
- Prisma Cloud
  - 構成情報をもってきてアセットの管理やコンプライアンスレポート等やっている
- この知見を使って診断
- わかった課題
  - 本番環境はちゃんとやるがそれ以外は見れていない
  - RDP/SSHが開いてる
  - MFA無効
  - 放置ユーザの管理
  - S3のチェックは結構重点的にやっている
  - ネットワークの対策はSecurity Groupに頼っていて困っている人は多い
  - 振る舞い検知や変更履歴
  - Inspector GuardDutyの利用は半分くらい
- どんなアラートをみれるか
  - ユーザアクティビティ
  - ネットワークアクティビティ
  - FlowLogsの可視化など
  - コンプライアンス管理
    - CIS
    - NIST
    - GDPR
    - 等
    - 柔軟にカスタマイズできる
- AWSセキュリティソリューションとの違い
  - リミデーションなどもできる
  - いろいろ肩代わりできるので使い分け
アットホームでのセキュリティ運用事例
- 斎藤氏
  - 情報システム部でインフラ基盤管理をしている
- 不動産の情報提供をしている
- インフラ環境状況
  - オンプレとクラウド半々
  - AWSアカウント60個
  - どんどん増えていく
- 課題: クラウド上で稼働している環境はセキュリティ上問題ないのか
- 具体的には
  - 社内ルールに準拠したシステム構成になっているか
  - 可視化
  - 横断的にチェックする負担が大きい
- Prisma(Redlock)を選定
  - 自動で定期的に複数AWS環境のチェック
  - 各コンプライアンス準拠のチェック
  - アラームの対策手順、案内があり便利、超探しやすい
  - AWSコンポーネントの可視化が可能
  - マルチクラウド対応
- 通信の可視化
  - 全体のサマリからクリックするとブレークダウン
- ユーザの振る舞い検知
  - 短時間で複数回のログイン施行
- 運用の流れ
  - Slack通知
- 導入効果
  - 導入当初のアラートの多さに驚愕
  - クラウドセキュリティの重要性を再認識
  - 対策にかかる工数の削減
- 今後の課題
  - 開発者へ共有してセキュリティ意識を高める
  - 自動修復

感想

コンプライアンスの管理に使える製品としてPrisma Cloudは非常にいいですね。

もちろんAWSのサービスを組み合わせていろいろできますが、すでに用意されている手段を活用できるのも強みですし、FlowLogsの可視化などとにかくよく見えるようになると思います。

こういったところは3rdパーティをうまく使いたいですね。

Session5: 株式会社サイバーディフェンス研究所西脇春名さん「インシデント発生！その時あなたは…～Digital Forensics on AWS～」

AWS上のフォレンジックとインシデントレスポンスについて
想定対象
- AWSを利用してなにかのサービスを誰かに提供位している開発者
- セキュリティ専門ではない方
- 技術ではなくメタ的な話
伝えたいこと
- インシデントは突然起きる
- フォレンジック屋さんはネクロマンサーではない
- ログがないなら何も変わらない
- 応急処置をするのはあなた
  - フォレンジック屋さんは端末の検視官だと思ってください
- 助けるのはあなたです
- 有事には備えましょう
インシデントに備える
- 自組織でどんな対応をするか手順は決まっていますか？
  - いつ誰にどのように報告するか
  - 利用者全員が知っていますか
  - してはいけないことは決まってますか？
- 状況を把握するために必要な情報はどこ
- システムの構成はトポロジは把握していますか
- ログ保存はどこに
- ログ取得のポリシーは定められているか
- ポリシーが守られているか
- 保存されチエルログを検索する方法は用意されていますか
- それをIR担当者が利用することはできますか
- やることはいっぱいある
インシデントレスポンスあるある
- フォレンジック担当者の愚痴なのでブログは割愛☆ミ
怖くない…ほーら怖くない…
- 攻撃を受けたり致命傷に至るのはだいたい使う人間のせい
- 悪いのはAWSじゃない
- せめて救助手順を整えておく
AWSのフォレンジック
- オンプレとは多少手順が変わる
  - HDDを抜けない
  - スナップショットを取って別インスタンスからイメージ保全
  - ストレージ暗号化されていても大丈夫
- それ以外はオンプレサーバと同じ
- CloudWatchとかあるのでオンプレよりも外部(S3とか)にログが残っていたりする
- サーバレスやコンテナフォレンジック調査などはログやコンテナ自体が残っていなければ調査できない(当たり前)
もし自社で調査をするなら
- AWSのフォレンジック用として発表されているツールがある
  - aws_ir
  - ssm-aquire
  - aws-security-automation
- それぞれ使えるシーンが違います
- まだPoCと思っておいたほうがいいです
  - 使えない状況がある
- 全部あんまり積極的にメンテされる感じがしない
軽く紹介
- aws_ir
  - Margarita shotgunを使ってメモリを保全したりユーザのAPIキーを無効化したり
  - 対応しているカーネルが必要でいきなり使うとうまくいかないことも
- ssm-aquire
  - メモリを保全したりOSQueryを使ってどこと通信しているかとか取得したりdockerでメモリを軽く解析したり
  - Windowsとかではうまくいかないことも
- aws-security-automation
  - EC2 Auto Clean Room forensicsというのを使ってみました
  - イメージングまでやる
  - 使える構成などが限定的
  - IRというより効率化っぽい
- インシデントが発生したからと行ってさっさと使ってあら便利というものではありません
人間が生み出す脅威には人間しか対応できない
- どんな便利な機能やサービスがAWS上に実装されたとしてもそれを使うのはユーザ
- 人間なので間違う、忘れる、悪意のある人もいる
- 油断や怠慢が高い出費になるかも