Security-JAWS 第16回レポート #secjaws #secjaws16 #jawsug

Security JAWS 第16回のレポートです。新サービスのDetectiveやIAMの濃い話、CCoEや組織のセキュリティをやっていく話、IMDSv2の話といろいろあります！

#JAWS-UG

#レポート

#セキュリティ

#AWS

臼田佳祐

2020.02.14

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

こんにちは、臼田です。

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

Security-JAWS 【第16回】勉強会 2020年2月14日(金) - Security-JAWS | Doorkeeper

レポート

Session1: アマゾンウェブサービスジャパン株式会社桐山隼人さん「Amazon DetectiveなどAWS re:Inventで発表されたセキュリティサービス紹介」

新しく発表されたAmazon Detectiveを含めたサービスなどを紹介します
クックパッドさんが喋った動画も上がっているので見てください
AWSのセキュリティ担当のシュミットさんが誰にでもセキュリティを届けるためにセキュリティ専門チームがやらないといけない事が多いと語る
- 簡単と難しいは対義語
- 単純と複雑も対義語
- 簡単にしないと使ってもらえない
- 簡単にセキュリティを利用するための仕組みは複雑
- 透過的、ReducedFriction、ガードレール、自動化、マネージドサービスを駆使していく必要がある
主要なセキュリティサービスアップデート
- 強力なマネージドサービス
  - IAM Access Analyzer
  - Amazon Detective
    - まだプレビュー
    - 検知したセキュリティイベントの調査を支援
その他のアップデートやセキュリティ関連アップデートもてんこ盛り！
Detectiveの話
- どういうことをするのか
- 例えばGuardDutyで検知すると
  - これまでのふるまいとは異なるコンソールログインが確認されたというFindings(結果)が出る
  - 結果が出たあとどうするのか
  - 今までは自分たちで深い調査をする
- GuardDutyは見つけるまで
- 不正なふるまいだと思われるものがGuardDutyで検知されたら
  - どのアカウントか？
  - どこからログインしたか？
  - 過去に履歴があるか
  - などなど
- 調査が難しい
  - ログの種類やデータ量は多い
  - 専用ツールも必要
- 検知したあとの対応・調査を行うのがDetective
- 統計分析、グラフ理論、機械学習を使って分析して可視化
- CloudTrail/FlowLogs/GuardDutyからログを自動収集して分析
- 利用イメージ
  - GuardDuty/Security HubのメニューでInvestigateが追加される
  - そのFindingsをDetectiveで調査できる
  - 例えばGeoマップ
    - 今まではUSからログインしていた
    - 今回はシドニーから来ているのが視覚的にわかる
  - もう少し調査
    - Overall API call volume
    - 成功したAPIと失敗したAPIがグラフで見る
    - 失敗がスパイクしている、成功が増えているなどが見れる
    - クレデンシャルが搾取されてそこから試行錯誤するAPIが増えていると分かる
  - どのリソースに攻撃があるか
    - 関連するFindingsも見れる
    - 例えばビットコインマイニングのFindingsとつながる
    - 関連するEC2インスタンスを確認でき、通信しているIPアドレスまで見れる
    - 時間軸のグラフがあり、インシデント発生後に通信が増えていることが見れる
  - 今までと違う傾向であることが分かる
- Detectiveによるデータ自動収集・分析
  - 自動的にやってくれるのでユーザが複雑な設定を行わなくていい
  - 中身にGraph DBが利用されている
    - Instance/User/IP/Role/Bucket/Findings等の要素がGraphでN:Nで紐付いている
  - Graphなのでこの関連を簡単にみることができる
IAM Access Analyzerとか他のサービスを紙芝居で紹介
- IAM Access Analyzer
  - 意図しないアクセス許可がされていないか簡単に見れる
  - アカウント外に公開しているリソースなど
- KMS
  - 公開鍵暗号サポート
- Cognito
  - Appleでサインイン
- SSO
  - SAML外部IDプロバイダ
- CLI
  - SSOで認証できる
- EC2
  - インスタンスメタデータ強化
  - IMDSv2
- WAF v2
  - ルールの記述の拡張
  - AWSのマネージドルール

感想

アップデートも盛りだくさんでいろいろ使って行きたいですね！

Detectiveはすごく調査が捗るので早くGA来てほしいですね！まずはプレビューに申し込んでフィードバックしていきましょう！

Session2: トヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント株式会社 Cyber&Vehicle Security シニアディレクター高橋威裕さん「様々なAWS Securityベストプラクティスのまとめ」

元々脆弱性研究者をやっていたので攻撃者目線で見ることが多い
TRI-ADは何をやっているか
- 自動運転
- Arena - 地球上で最もプログラマブルの車のプラットフォーム
  - 仮想化されたプラットフォーム
  - 様々なアプリケーション開発者に使ってもらいたい
- WovenCity - コネクテッドシティ
様々なAWSセキュリティのベストプラクティス
- AWSでも様々なパートナーもいろんなことを言っている
- たくさんあってどこからやったらいいか分からない
  - 自分の組織に当てはまるものがわからないからかも
- AWSから出ているホワイトペーパーも116ページあって大変
- AWS Re:Inforce 2019のYoutubeのプレゼンは109個
- しかしどれも濃くていい
- 嬉しい意味で多い
クラウドを使う理由とセキュリティチームの役割
- 開発チームのアジリティ向上、ビジネス加速
- セキュリティチームは開発チームのために適切なリスク管理をする
  - 事故につながらない仕組みづくり
  - 使い方のルールづくり
- リスクを考えて要所要所にベストプラクティスを埋め込む
一般的なセキュリティの考え方
- 侵入されることを前提に、被害の範囲を最小限に抑えるデザイン
- 与える権限は最小限に
- ユーザとパスワードはアンチパターン、2FA
- 多重防御
- 脅威モデルを作成、脅威と対応策を明確化
セキュリティ向上への道筋
- 攻撃手段を理解
- 自分のインフラの脅威モデルを作成
- 脅威ごとに優先度を決定
- 脅威に対応するベストプラクティスを実践して対処
- 定期的に脅威モデルを更新
攻撃について考える
- 実際にやられるケースは限られている
- 認証を要求しないリソースへのインターネットからのアクセス
  - S3オープン
  - Elasticsearch
- Githubなどの公開レポジトリにAWSのAPIキーを公開
- RCEやSSRFによりIAM Roleの権限を抜かれてアクセス
- 他にも
  - AMIにクレデンシャルを埋め込んで公開
  - rootやIAM Userのパスワードを使いまわしてアクセスされる
  - Rootで入られてデータを削除される
  - 組織を離れた人がアクセス
自分たちが始められるところから始めるといい
脅威モデルとは
- 例
  - インターネットに向いているEC2インスタンスにRCEの脆弱性が報告される
  - 緊急度Critical
  - ホストを特定して完了するまでトラフィックをLBで落とす
  - パッチ適用後にサービス開始
想定すべき脅威・リスク
- 先程の攻撃事例すべて
- AWSの管理者権限を持つ端末がマルウェア感染
- ADがハッキングにあう
- CI/CDの設定を変更できる人の端末が感染
- AWSの管理権限を持つ人がたくさんいる
- ウェブフレームワークに脆弱性発見
  - どのサービスがそのフレームワークを使っているEC2なのか分からない
- EC2のRoleの権限が大きすぎる
  - 奪われたら色々できちゃう
ベストプラクティスの探し方
- 正しい基礎知識を得る
- 攻撃者の一般的な手口を理解する
- ファーストパーティが提供しているレファレンスとなるマテリアルを理解する
  - re:Inventやre:Inforceなど
- 著名なAWS Security 専門家の直近2年位のコンテンツをレビュー
  - Scott PiperやSecurosisのホワイトペーパーやBlogを読む
- 自分の環境に落とし込む
ベストプラクティスの探し方(ショート版)
- ファーストパーティが提供する
- AWS Security Maturity Roadmapを読む
在庫チェックと可視化
- 社内で使われているAWSアカウントとオーナーのリストを作成
  - AWS OrganizationsやSPC利用
- 各アカウントに存在するリソースを洗い出し
- セキュリティ用のAWSアカウントを作成
まとめ
- 脅威を理解してモデルを作って優先度をつけてまずいものから対応
- AWSのYoutubeはいい
- Scottさんのマテリアルはいい！

感想

密度の濃い内容でした！マテリアルをみるのです！

Session3: 森永乳業株式会社経営戦略本部 IT改革推進部アシスタントマネージャー石井俊光さん「事業会社情シスとしてのセキュリティの取り組み（CCoE立ち上げと今後の展望）」

Security-JAWSに1年前くらいから参加している
情シスのような部署でクラウド推進チームのリーダーを行っている
森永乳業のITの歴史
- IBM360/40の始動式を50年前にやった
古くからやっていたが課題も多い
- システム投資抑制、短期視点
- 老化していった
2017年に改革を始めた
- 組織も変えて情報システム部からIT改革推進部と情報システムセンターにする
- 攻めのITへの転換を図った
改革によって人材確保などができるようになっていった
守りのITと攻めのITを両立
- 守りのIT(Mode1)
  - クラウド化を検討してAWSへ移行した
  - AWSクラウドエコノミクスを実施
  - 約60%のコストダウンができる見積もり
  - AWS移行検証を行った
- 攻めのIT(Mode2)
  - 外部環境や市場環境が変わってきている
  - 投資リスクや人材が課題になる
  - 今まではビジネス部門の要望を叶えるのが難しかった
CCoEを設立した
- クラウドを推進する専門組織
- CCoEの形態は企業により違う
- 森永乳業はIT部門内にバーチャルで設置
- パートナーにも入ってもらうが自社で主体的に行う体制に
- クラウド活用方針を定めた
  - 標準化をしていく
    - オンプレミスを基準にしないように
  - 分析改善
    - AWSのアカウントが増えてもいいように共通基盤を実装
  - 新技術検証
    - ビジネス部門から上がった課題を手当り次第実行
    - 既存のITでは考えられないスピードで実行できた
CCoEの今後
- IT部門から離れて部門横断で活躍できるようにしていく
重要になるのがセキュリティ
- 事業会社で非ITのセキュリティの課題
  - 経営との距離が遠い
  - 新規予算がつきにくい
  - 人材の不足
  - ローテーションや教育
- 自社でクラウドセキュリティの考え方を定義
  - クラウドシフト、クラウドファーストのためにセキュリティが最重要課題と位置づけ
  - 自社で手を動かしながら習得
    - WebサイトをAWS移管(内製化)
    - これまでは外部委託だった
    - 少しずつ移して50サイトほど移管できた
  - ほぼ丸投げから内製化できて新しいチャレンジのための予算を確保できた
  - マルチアカウントでログ分析基盤を作っている
- マネージドサービスをフル活用
  - 不足する部分はセキュリティベンダーを頼る
  - セキュリティ対策方針を策定
    - 環境のレベルごとに定義
    - マネージドサービスも駆使
    - サードパーティの製品も駆使
まとめ(自社の取り組み、考え方)
- 適当な「丸投げ」案件を探す
- 手を動かして習得、改善していく
- ツールを活用して負荷を減らす
- 手に負えない部分は専門家を頼る

感想

外部への丸投げから頑張って内製化していっているのは素晴らしいですね！

CCoEのあり方は様々ですが、事業会社の方は参考になるかと思います！

Session4: 株式会社FOLIO 鈴木研吾 (ken5scal)さん「IAMどうしましょ」

IAMなにもわからん
今回の目的
- IAM周りの相談をしたい
- sli.doを使う
前提
- 当たり前にやること
- IdPとのSSO
- マルチアカウント・Organization構成
IAM Policy vs Resource Policy
- 両方合致したらアクセスできる
  - IAMは何に対して何をできるか
  - Resourceは誰が何をできるのか
- マルチアカウントならRoleとBucket両方指定できていないとアクセスできない
- 使い分けどうするか
  - ANDなので両方定義しなければならない
  - 基本方針は？
  - ken5scalの個人的見解: IAM Policy側に寄せる
- 最初はこう思っていた
  - IAMという入り口を各種リソースに依存させたくない
    - リソースで縛る
- 今はこう
  - Identityへの認可という意味で、IAM側に設定をつけるのが理想的にただしそう
  - リソース毎の制御は運用的に大変
    - RoleよりBucketのほうが増えるのでは
- 結局IAMよくわからん
Permission Boundary
- 使い方がわりとわからん
- Boundaryで許可されていないと許可されない
- 何をDelegateしたらいいかわからん
- IAMなにもわからん
Tag Based Access
- リソースに対してタグを付けて、それを利用してアクセス
- Conditionでタグを指定
- リソースは全許可だが指定のタグがないとアクセスできない
- Putもオブジェクトにタグがないといけないようにする
- 例えばOwner/Confiタグがないと行けない
- バックエンドはもっとタグを増やしてセンシティブなものを管理
実際の運用
- ABAC(属性ベースのアクセスコントロール)をやっていきたい気持ちはある
- タグの運用が大変・手間そう
  - タグ運用ルールつくる
  - タグ警察爆誕するのか
- OrganizationsのTag Policiesとセットでやらないといけなさそう
- ECSタスクのRoleにServiceタグを付けてRDSアクセスをタグ制御できると夢が広がる
- ここはわかった
AWS SSO vs IAM Role
- 似たようなことができる
- 別のRoleに変えたいときは一旦ログアウト
- AWS SSOなら簡単
- PermissionはAWS SSOでも優れている
  - IAMは各アカウント毎定義しないといけない
  - でもIaCやっていたらそこまでアドバンテージにならない
  - AWS SSOで今の所タグベースは自動で出来ない
  - Custom Policyは1:1
- CLI
  - aws sso loginは少し面倒
  - cli充実しないかな
- 今のところはIAM Role利用のほうがよさそう
- IAMなにもわからん

感想

全般的にIAMは複雑なので大変ですな。

前回IAMの薄い本の話がありましたが更にその発展の話に感じました。

なにもわからん！どうやって行くかは手探りが必要ですね。

Session5: EGセキュアソリューションズ株式会社徳丸浩さん「SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方」

[slideshare id=227915347&doc=introduction-to-imdsv2-200214075008]

IMDS(v1)
- インスタンスメタデータサービス
- インスタンスから仮想のエンドポイントへアクセス
- 設定情報を取得できる
- curlなどでアクセス
- インスタンスからアクセスしたら情報が取れる
Capital Oneの事故
- WAFの設定ミスから情報漏えい
- Apache + mod_securityのインスタンスを経由してWAFのインスタンスへアクセス
脆弱なWAFの作り方(再現してみた)
- こんな感じ(スライド参照)
- リバースプロキシがオープンプロキシに
- なぜか
  - mod_proxyでProxyRequestsをON
  - インターネットも危険に
- オープンプロキシだったとしてもインスタンスに当てられたRoleが最小権限だったら良かった
- でもすべてのS3にアクセスできるようになっていた
- アクセスしてみる
  - mod_securityがブロックしている
  - 適当なホスト名をつけると突破可能
  - クレデンシャルも、ほれ
- クレデンシャルをawscliにセット
- S3の情報を取得できた
IMDSv2がでてきた
- v2へのアクセスには事前に取得したTokenを必須とする
  - PUTで取得
  - 有効期限を設定
  - Tokenをヘッダに入れてリクエストする必要がある
- こちらも参照
- Token取得後メタデータにアクセスできる
IMDSv2効果まとめ
- PUTメソッドでトークン取得
- トークンをヘッダに入れる必要がある
- X-Fowarded-Forがあるとブロック
アプリケーションの脆弱性がある場合
- プレビュー機能でSSRF攻撃
- IMDSv1だとホスト名指定で回避できる
- v2なら突破できないのでは？
- Gopherプロトコルで突破できる
  - 古いプロトコル
- curl gopher://...でHTTPをエミュレートできる
- PUTから順に実行できてしまう
- やってみよう
  - できた
- URLのスキームをバリデーションすればいいのでは？
  - リダイレクタによる攻撃
  - 外部のサイトにリダイレクタを設置してLocationで攻撃
  - バリデーション後なので防げない
- リダイレクトを追跡する設定がなければ回避できる
対策
- ネットワーク的な保護
  - URLの完全な検証は難しいのでネットワーク的な保護が有効
- IMDS自体使わないなら無効化
- どちらかの対策は必要
まとめ
- 脆弱なWAFが作れる
  - 公開したらインターネット全体が危険になるので注意
- IMDSv2の効果と限界
  - ネットワーク的な防御や無効化を検討
- 総合的な脅威分析が必要