Security-JAWS 第21回レポート #secjaws #secjaws21 #jawsug

Security JAWS 第21回のレポートです。AWS WAFの最新情報からIAMの最小権限、金融APIをAPI Gatewayで実現する話、そしてAzure SentinelでCloudTrailを分析する話でした。そして何でも答える質問コーナーです！

#JAWS-UG

#セキュリティ

#レポート

#AWS

臼田佳祐

2021.05.19

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

こんにちは、臼田です。

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

Security-JAWS 【第21回】勉強会 2021年5月19日(水) - Security-JAWS | Doorkeeper

動画

レポート

Session1: 「AWS エッジサービス入門ハンズオンの紹介とAWS WAFのアップデートについて」アマゾンウェブサービスジャパン株式会社テクニカルソリューションアーキテクト文珠啓介さん

前半はAWSエッジサービス入門ハンズオンの紹介
後半はAWS WAFのアップデートについて
セキュリティイベントでなんでエッジ？となるかもしれないが、なるべく前段で危ないリクエストを止めることはセキュリティ上重要
AWS Hands-on for Beginnersとは？
- 実際に手を動かしながらAWSのサービスを触れる
- いろんなハンズオン資料があるよ！
- 上記URLからアクセスして、自分のAWSアカウントを用意してチャレンジ
エッジサービスのハンズオンコンテンツを作成した
- エッジサービスとはなんだっけ？ということから説明している
- 簡単に説明
  - ユーザーはサーバーから距離があると遅く感じる
  - ユーザーにとってはエッジロケーションでキャッシュがあると快適に利用できる
  - オリジンサーバーは負荷が軽減する
  - 細かい内容は本編をみてね！
- ハンズオンでは実際の設定についてもわかりやすく説明
  - 例えばCloudFrontではDistributionやBehaviorといった用語についてわかりやすく説明
- 実際にキャッシュを確かめるということも確かめられる
- AWS WAFについてもハンズオンに含まれているが今回は割愛
AWS WAFのアップデート
- AWS WAFの簡単な振り返り
  - ALBやCloudFrontなどのフロントでリクエストをブロックできる
  - 悪意のあるリクエストや、カスタムルールに基づくブロック
  - ブロックしたメトリクスやログを確認して分析
- AWS WAF Bot Control
  - AWS WAFでボットと判断されるトラフィックを検知したらそれに対してアクションできる
  - ブロックしたりラベル付けできる
  - サーバーリソースがボットで食いつぶされたりすることを防げる
  - AWS WAFを使っていれば、Bot Controlを有効化しなくてもボットの可視化ができるので、導入を検討する材料にできる！(すごいいい)
    - 情報は1日遅れでサンプリングしているので、参考程度に
  - Bot Controlを有効化すればもっと詳細なレポートが確認できる
  - リクエストの課金以外にベースフィーもかかる
  - 設定はマネージドルールの1つとして有効化する
    - 最初はカウントモードでの導入を推奨
- ラベル機能
  - リクエストに対して追加されるメタデータ
  - カスタムルールでラベルに基づいてアクションできるので、これと組み合わせる
- スコープダウンステートメント
  - ルールの適用範囲を限定することができる
  - 例えば/loginにのみ対してルールを適用するなど
- カスタムレスポンス
  - カスタムルールの中で設定できる
  - レスポンスコードやbodyを変えれる
- リクエストヘッダの追加
  - バックエンドにリクエストを転送するものについてヘッダを追加
  - ラベルと組み合わせることも
  - 例えばBotと検知したものを通して通常と違うアクションをするなど
- ログフィルタリング
  - ログをフィルタリングする
  - 例えばBlockのログだけ出すなど
  - 後段のKinesis firehoseやS3の料金を低減

感想

最近のAWS WAFのアップデートは本当に使い方が1段階あがってめっちゃいいものばかりですね！

ガンガン使っていきましょう！

Session2: 「Well-ArchitectedなIAMポリシーに挑戦する（改）〜最小権限の原則を実装ってどゆこと〜」日本電気株式会社大竹孝昌さん

今日のお話はJAWS DAYS 2021のハンズオン資料がベース
- 最小権限って何？
- 具体的なやりかた
原理原則の理解
- Well-Archtectedフレームワークを見よう
- SEC 3: 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
  - こうしたほうが良いというベストプラクティスと改善計画がある
    - Roleに最小権限を割り当てる
    - 必要じゃないアクセス許可を削除する
- あるIAMユーザーにあんな権限こんな権限を当ててしまう事がよくある
- 混ぜるな危険
- 以下3つ定義する
  - アクセス権限が必要となる条件を定義 -> 役割(Role)
  - 実行する具体的なアクション -> API
  - 操作対象のAWSリソース -> ARN
ロール
- ロールは状況に応じて使い分けよう
- あの役割この役割
- 役割毎に権限を変える、まぜない
絞り込み例1
- EC2インスタンスの運用
  - 目視確認をすることを運用と定義
  - 閲覧に関係するもの全般を許可
    - EC2やVPCなど
  - 対象のARNは制限なし、どのEC2も見れる
  - この場合はAPIはReadOnlyAccessを活用する
- EC2インスタンスの起動と停止もつけたい
  - 閲覧以外の起動と停止を追加する
  - ReadOnlyAccess以外にカスタムポリシーを使う
  - ビジュアルエディターが活用できる
  - アクションがたくさん出てきて大変
  - どうするか
  - CloudShellとAWS CLIの組み合わせがいい
  - AWS CLIは命名規則がシンプルだから実行するアクションがわかりやすい
  - start-instancesなど
  - 類推は必要
  - 実際にCloudShellで試してみると求めているものか確認できる
ReadOnlyAccessは本当に安全か？
- いろんなリソースのReadが入っている
- 見る必要がないデータにもアクセス可能
- 情報漏えいのリスクと考えることもできる
- W-AフレームワークのSEC 8では人をデータから遠ざけるとある
- データに触れないようにしたほうが良い
- ReadOnly = 安全という解釈は必ずしも正しくない、リスクはある
厳密には最小権限のポリシーとはもっとも絞り込んだ権限
- EC2の閲覧ならそれだけに絞り込むなど
- ワイルドカードを指定していると要注意
- 絞り込まないリスクをどこまで考えるのが大事
都度AWS CLIでやると面倒
- CloudFormationが絡むと心が折れる
- 楽な方が良いよね
絞り込み例2
- CloudTrailを活用する
- AWS CLIだけじゃなくて画面で操作したものもCloudTrailなら確認できる
- CloudFormationを使って確かめる
- いろいろ混ざるのでマーカーイベントを仕込むといいのでは
- 今回はCloudShellを使う
- 何も考えずに適当なコマンドを3連続で実行する
- CloudTrailのログを追うときに見つけやすくなる
- 気分はsync sync sync
- それをCloudTrailのイベント履歴でイベント名指定して確認
- イベント時間から、自分の確認したい時間を確認
- 時間を指定して履歴を絞ることが可能なのでこれを使う
- 注意点としては制御できないものも入っているので無視するなど
- あとは実際に試す
- ちまちまピックアップする
衝撃ニュースが！
- 4月にIAM Access Analyzerを使って権限を抜き出す機能が追加！
- 詳細は次のセッションで！

感想

最小権限の実現は大変ですが、リスクも考えつつうまくやるのが大事ですね

細かいコツは非常に参考になるので参考にしましょう！

Session3: 「IAM Access Analyzerを活用して最小権限を目指そう」クラスメソッド株式会社ソリューションアーキテクト千葉幸宏さん

資料とかはこちら

話さないこと
- IAM Access Analyzerの具体的な使い方については話さない
最小権限とは
- 最小権限ってどこに書いてある
  - IAMのセキュリティベストプラクティス
    - 新しい機能でいろいろ対応できるようになっている
  - W-Aフレームワークのセキュリティの柱
    - ユーザーに持たせる権限をどうやって設計するか
    - カスタマー管理ポリシーを作って使う必要がある
    - 条件、リソース、アクションを最小化する
    - リソースやIAMアイデンティティにアタッチするポリシーを限定する
- 最小権限が守られていない場合
  - 操作ミスによる意図しない変更
  - 不正アクセス
  - 内部犯行
- 狭く始めて必要に応じ追加が理想
  - 最初は緩めというのもあるが、本当は狭くがいい
どこで最小権限を実現するか
- ポリシーの種類
  - AWSでは6つのポリシータイプがある
  - アイデンティティベースポリシー
  - リソースベースポリシー
  - アクセス許可の境界
  - Organizations SCP
  - アクセスコントロールリスト
  - セッションポリシー
- それぞれほとんどJSONでできている
- JSONポリシーの要素
  - Statementに細かい要素が入っている
  - Principalは誰が
  - Actionは何を
  - Resource何に対して
  - Conditionはどんな場合に(任意)
- 最小権限はアイデンティティベースポリシーでActionを絞るだけではない
  - いろんなところでやっていく
IAM Access Analyzerとは
- リソースベースポリシーのPrincipalを見てくれるものだった
- いつの間にか色々できるようになった
- リリースは2019/12
- S3やIAMロールなどのリソースベースポリシーを分析
- 事前検証などが後から追加
- 2021/3にポリシーチェックが追加
  - アイデンティティベースポリシーのチェック
- 2021/4にポリシーの生成に対応
  - アイデンティティベースポリシーが対象
- リソースベースポリシーの分析はアナライザーというリソースを使う
- 新しい機能はアナライザーは無く使える
- IAMアクセスアドバイザーと混同しがち
  - 大きく違うのはサービスかどうか
  - アドバイザーはサービスではなく複数のAPIによる機能
  - アドバイザーはアイデンティティベースポリシーを基準としたアクセス可能なサービスの表示
最小権限を目指すための機能
- ポリシーの検証
  - 以下をいい感じにチェック
    - アイデンティティベースポリシー
    - SCP(CLIのみ)
    - リソースベースポリシー(CLIのみ)
  - チェック観点
    - セキュリティ
    - エラー
    - 警告
    - 提案
  - セキュリティのカテゴリのチェック項目例
    - NotPrincipalで許可を与えている
      - 書いてないものに許可が与えられる
    - PassRoleが広すぎる
    - EC2のフルアクセスなどは見てくれない
  - マネジメントコンソールから使うときは何も考えずに使う
  - ポリシーをCI/CD管理しているときには自動で検証させる
  - 最小権限のためにはそこまで強く活用できるわけではない
- ポリシーの生成
  - IAM Access Analyzerによる機能
  - 過去のアクティビティを基にアイデンティティベースポリシーの雛形を生成してくれる
  - アツい機能！
  - 注意点があります
  - 注意点1
    - 過去のアクティビティが前提なので最小でスタートのケースでは使えない
    - 期間が90日
    - 生成できるのは1日5件まで
    - などなど
  - 注意点2
    - 精査してくれるのはActionのみ
    - ResourceやConditionには過去のアクティビティは反映されない
  - 注意点3
    - すべてのサービスで精査してくれるわけではない
  - 開発機関の実績のもと最小権限を目指すというケースでは有効
  - アイデンティティベースポリシーのActionを絞る用途にしか使えない
  - Actionが全て洗い出されるわけではないのが注意
最終アクセス情報を使う
- アクセスアドバイザーの機能
- 機能としてできることは少ないがお手軽に使える
- AWS CLIでフィルタリングや抽出をやると楽しい
まとめ
- 最小権限はいろんなポリシーの色んな要素を使って実装
- Analyzerやアドバイザーは一部をチューニングに便利
- これさえやっておけばOKではないので頭を悩ませよう

感想

注意点はあるものの、最小権限のための革命的な機能だと思います！

まずは使ってみよう！

Session4:「金融グレード Amazon API Gateway」株式会社 Authlete 森川将聖さん

Authleteというサービスを提供している
- OAuth/OIDC実装を実現する
- 提供するAPIを使うと簡単にOAuth/OIDCが実現できる
- サービス事業者は最先端の業界標準に準拠した機能が利用できる
OAuth2.0の基本的なシーケンス
- 認可リクエストを受けたら認可コードを返す
- 認可コードをもらったらアクセストークンを返す
- アクセストークン付きのAPIリクエストを受け付けてレスポンスを返す
- OAuth Danceとも呼ばれる
Financial-grade API(FAPI)
- 金融API向けのOAuth2.0適用プラクティス
- 様々な立場の専門家が使用策定に集結
FAPIにおけるOAuth Danceの改善
- 4つある
- 今回はトークンの漏洩・盗用防止について詳細に話す
MTLSによる送信者制限
- クライアント証明書にアクセストークンをバインド
証明書バインディング
- クライアントアプリがクライアント証明書を提示してアクセストークンをクライアントアプリが受け取る
- リソースサーバーに証明書とアクセストークンを送る
Amazon API Gateway
- 2020/09からMTLSをサポート
- クライアント証明書を取り出すことも可能
- 証明書バインディングに対応したAPI構築が可能に！
Amazon API Gatewayで金融グレードAPIを実現
- APIG
  - MTLSの有効化
  - Lambdaオーソライザーの設定
    - APIコールからアクセストークンと証明書を取り出す
    - Authleteにアクセストークンの検証を移譲
- Authlete
  - 証明書バインディングの機能を有効化
MTLS設定に必要なもの
- カスタムドメイン用のサーバー証明書
  - APIGにカスタムとメインを割り当て
  - サーバー証明書がACM管理下に置かれている必要がある
  - ドメインの詳細で設定
  - トラストストアのURI設定(S3 URI)
- トラストストア
  - 信頼するクライアント証明書郡を含むファイル
オーソライザーの役割
- アクセストークンと証明書を取り出す
- Authleteに渡して検証してもらう
- 結果をオーソライザーが受け取ってポリシーや例外を作成
- 実装はPythonのライブラリが公開されている
- 証明書の取り出し
  - APIGのペイロードバージョンによって格納場所が違う
  - ライブラリでは2.0で取得できない場合には1.0で取得するという処理にしている
オーソライザーの設定
- Lambdaイベントペイロードはリクエスト
- Lambda関数に環境変数を設定
- タイムアウト値の設定
  - 外部サービスなので少し長めが推奨
Authleteの設定
- サービス(認可サーバー)の設定
  - 管理者コンソールから証明書バインディングを有効化
- クライアントアプリケーションの設定
  - 開発者コンソールから証明書バインディングを有効化
MTLSによる送信者制限のAPIリクエスト部分がこれで実現できるように
証明書バインディングの効果
- 双方向TLSによりリクエスト送信者を特定しトークンの不正利用を防止
- 攻撃者はトークンを盗んで持っていても、秘密鍵を持っていないのでリクエストを拒否できる
まとめ
- FAPI
  - 高度なAPIセキュリティを実現するための技術仕様
- APIG
  - FAPIに対応した構築が可能に
- みなさんFAPI対応をやっていきましょう
Authleteの無料トライアルもあるよ！

感想

FAPIについて具体的に知らなかったのでよくわかりました！

APIGのMTLS対応はこういうところに役に立つんですね。ぜひチェックしてみてください！

Session5: 「Azure SentinelでCloudTrailのログを分析するということ」株式会社クラウドネイティブ吉田浩和さん

注意事項
- 個人の見解に基づくものです！などなど
ログを分析するだけならば好きなツールを使えば良いんじゃないか
- 分析する目的によって扱う人や対象ログ、必要な機能が異なるから
持って返ってほしいもの
- 誰がなんのためにログ分析して何を得られればよかったの？に立ち返るきっかけ
- ひょっとしたら固定観念にとらわれている人の打破の手がかり
- お絵かきが得意な人にちょっとした気付き
AWSのログってどんなのがあったっけ？
- CloudTrail
- Config
- ELB
- CloudFront
- WAF
- S3サーバーアクセスログ
- CloudWatch Logsに流すやつ
- Security Hub
- などなど
今日はCloudTrailだけ
- ログは1つのシステムで分析できないとね！
- ほんとぉ〜？
- AWSのログが網羅されていればいいんだっけ？
ビジネスシステムのスコープ
- AWS以外もいろいろあるよね？
- オンプレデータセンターや社員の端末などなど
いろんなログを見なければいけない
- Operations CloudHopper
  - MSPを標的とした攻撃キャンペーン
  - 一種のサプライチェーン攻撃
- マイネットグループの問題
  - ビジネスチャット上で共有しているアクセス情報を盗み見られた可能性
正規のアクセス情報/経路を通じて攻撃が仕掛けられる時代
- 裏口から入られる
- AWSだけ見てれば良いんでしたっけ？
見なければ行けない内容一例
- 監視
  - サービス稼働
  - 障害調査
- サービス利用
  - サービス利用傾向
- 追跡調査
  - サービス不正利用の追跡
  - 外部からの攻撃の把握と追跡
  - ログイン状況の追跡
  - 管理者操作の把握と追跡
- いろんなチームがみる
- サービスは多くがAWSに収まる
- 追跡調査部分はAWSだけに収まらない
1つのシステムでできるに越したことはないが縛られる必要はない
- 分析する目的によって人やログや機能が違うから
自身のビジネス環境と用途に即したログ分析基盤が必要
注意
- 無秩序にツールを乱立すれば良いわけではない
- 目的と計画、基盤維持と組織体制があって成り立つ
- ログ分析基盤やアクセスコントロールや原本管理などにも注意
- NIST SP800-92も参照してね
- 3回読もう
Azure Sentinelの紹介
- Cloud型SIEM
  - 古き良きストレージを準備してーとかそういうのは一切いらない
- 分析、可視化、自動化の機能
- 豊富な事前定義のテンプレート
- Kusto Query Language
- Azure環境との高い親和性
- 豊富なコネクタ
- APIの用意
- ログ流入量と保存期間で課金
  - 特別なライセンス不要
立ち上げ
- 工数は少ない
- サブスクリプションを使って数クリックでオンボード
- AWSとの接続はIAMポリシーとロール
- 20分くらいでOK
事前定義の分析テンプレートがある
- CSPM的なやつ
  - MFA使わないでログインしてるとか
  - いろいろある
- 不審な挙動のやつ
  - AWSにログイン成功したけどAzureADのログインに失敗している
  - 上記の逆
  - AWSのクレデンシャルが乗っ取られているかも
- 脅威インテリジェンスと連携
- MITER ATT&CKの戦術に基づく事前定義のハンティングクエリ
  - 侵害されていることを前提に分析する
- クエリサンプル
  - (ここにはかけないので資料とか動画とかみてね)
  - 対象のAPIを書いたり、UserAgentを確認したり
- すぐに使える事前定義のテンプレートがクエリの参考になる
事前定義のテンプレート
- ネットワークとユーザーの可視化テンプレート
- この中身もクエリ
- 可視化部分はぽちぽちして切り替える
自動化
- AzureのLogicAppでローコード実装
- 検知した内容は通知だけ
- 受け取る側はもう少し情報がほしいのでいろいろ取得してSlackなどに配信する
- 応用したらインタラクティブな通知もできる
  - 例えばアラートに心当たりがあるかどうかSlackでボタンを押せるようにするなど
ログは生き物で環境に合わせた作り込みが必要
アラートの相関もIPアドレスやユーザー名をキーにできる
- グラフで可視化できる
行動分析できる
コネクタいっぱいある
- サードパーティのセキュリティ製品とかも
つなぎこみと相関分析の観点でAzure Sentinelはいいぞ〜
やってみるとわかるクラウドでのログを扱う痛み
- ログの長期保管
  - Azure Sentinel自体のログ保存は最大23ヶ月(90日以内なら課金されない)
  - エクスポートは一部ログのみ
  - APIを使ったエクスポートはリミットにかかるなど
- 長期保管からの再分析
  - 大量に入れると時間がかかる
  - 長期保存先で直接分析できないとしんどい
  - Data Explorereは高額
- クラウドのログは結果整合性
  - ログは操作が行われてからすぐに読み取り可能にはならない
  - CloudTrailは8−12分程度
  - Trail -> Sentinelとやると約20分くらい
  - データソースによってまちまち
  - 即時アラートは無理筋
- 短気は損気、クラウドのログの相関分析は時間に余裕をもって

感想

Azure SentinelはいいSIEMのソリューションなので、CloudTrailの分析先として使うのは私もありだと思います。

AWSとかAzureとか関係なく良いものは使えばいいですね！もちろんAWS上でSIEMを実現する手段もいっぱいあるので、目的や使う人や機能を考えながら検討しましょう！

[クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー

質問1

SIEM on Amazon ESはAWS loft ハンズオンで触った程度で便利だなと思った一方、Amazon ESのお守りとか、実際に運用されている人の話を聞けるのであれば、お伺いしたいです。Amazon ESの運用をしたことがなく、ロギング、可視化に集中できるのかなど、さっくりな話を聞けるだけでも嬉しいです。