こんにちは、ひろかずです。
2023年3月10日に開催された「AWS Security and Risk Management Forum ～公共・金融DXの大前提 AWSセキュリティの理解と実戦〜」に行ってきたので、一筆書きます。

TL;DR的な何か

• 経済安全保障推進法やデジタル庁のガバメントクラウド、ヘルスケア業界での事例など興味深い内容が盛りだくさんでした
• AWSが普段から公共・金融分野にどのように向き合ってきたかを垣間見れる内容でした
• アーカイブが公開されるようなので、興味あるセッションは是非チェックしてみてください(2023年3月12日時点では未公開)

イベント情報

AWS Security and Risk Management Forum ～公共・金融DXの大前提 AWSセキュリティの理解と実戦〜
https://v2.nex-pro.com/campaign/50978/apply

お品書き

• クラウド時代におけるリスク管理と最新のセキュリティサービス活用によるイノベーションの加速
• 経済安全保障推進法の本格施行に向けた展望と対応
• ガバメントクラウドでのセキュリティの考え方～範囲の絞り込みと日々の監視・修正
• クラウドリスク管理の進展、金融業界における教訓と、現時点で責任者が認識すべきこと
• 100ヶ国＆50万顧客に支持されるセキュリティプラットフォーマーが描くAWSセキュリティのデザイン
• Amazon GuardDutyを活用した脅威検知・通知サービスのご紹介
• AWSを使った医療機関等におけるランサムウェア対策

クラウド時代におけるリスク管理と最新のセキュリティサービス活用によるイノベーションの加速

アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 統括本部長 / プリンシパルソリューションアーキテクト
瀧澤 与一 氏

公共・金融DXの大前提 AWSセキュリティの理解と実戦をするために役立つ情報を提供する日
Amazonは地球上でもっとも顧客を大切にする企業

• クラウドセキュリティは、AWSの最優先事項
• もっとも高いレベルのセキュリティで設計されている
• オンプレでもいろいろなやり方があったが、クラウドでよりやりやすくなる
  • 優れた可視性
  • 自動対処
  • この二つはGuardDutyが対応範囲で、他サービスと連携して実現する
    • 脅威を検知して、CloudWatchに通知、Lambdaでインシデント対応
      • 休日夜間での対応の遅れがなくなる
• クラウドを使う事での、リスク管理とセキュリティの考え方を伝えていく

アマゾン ウェブ サービス ジャパン合同会社
金融事業開発本部 コンプライアンス スペシャリスト
高野 敦史 氏

金融にフォーカス
AWSは2006年にサービス開始。東京リージョンは2011年に開設
日本リージョンの中での累計投資額は1兆3520億円

• そんなにやすやすと撤退しないよ！

金融機関の経営トップが、自分の口でAWSでどうセキュリティを実現しているかを語っている

AWSを活用することで、リスクを考える必要がある
ステークホルダーが広がっていく

• ビジネス部門、IT・開発、セキュリティ、リスク管理部門...

クラウドのリスクマネジメントで抑えておきたいこと

• 知らなかったをなくす
• クラウドにも影響ある金融規制の動向
• クラウドにも関係する日本の法律

知らなかったをなくす

• よくあるクラウドの誤解
• 耐障害性・高可用性の観点では、オンプレより高いというレポートも出ている
  • 海外リージョンの並行利用

クラウドにも影響ある金融規制の動向

• オペレーショナルレジリエンス確保に向けた基本的な考え方（案）
  • 重要な業務を最低限維持すべき水準において、提供し続ける能力
  • 業務中断が生じることを前提に利用者目線で商機復旧。影響範囲の軽減を確保する枠組み
  • 重要なサードパーティの特定とリスク管理
• カオスエンジニアリング
  • サーバーダウンやSoftware障害、トラフィックのスパイクやスケールなど障害でないイベントを人為的に起こして、対応出来るかを実験する

クラウドにも関係する日本の法律

• 経済安全保障推進法
  • 金融機関の経営トップの最関心事

---

経済安全保障推進法の本格施行に向けた展望と対応

西村あさひ法律事務所
弁護士・ニューヨーク州弁護士
桜田 雄紀 氏

基幹インフラの安定供給確保を中心に話す
2022年5月成立・公布
背景

• 米中覇権争い
• 技術革新による、軍事と一般の差がなくなってきた
• ウクライナにみられるハイブリッド戦争
  • 有事と非有事の差がなくなってきた

4つの柱

• 支援系(運用開始済み)
  • 重要物資のサプライチェーンの強靱化
  • 重要技術の官民連携育成支援
• 規制系(パブコメ中)
  • 基幹インフラ役務の安定的な提供の確保
  • 機微な技術分野の発明に係わる特許非公開化
• これらは基本的に別個のもので、外資規制ではない
• 司令塔は国家安全保障局だが、省令の策定や審査は各省庁
• 法律レベルは制度の外縁のみで、詳細は省令を出してから運用開始

重要物資のサプライチェーンの強靱化

• 政令によって、11の支援対象物資を指定
• クラウドプログラムも含まれている

基幹インフラ役務の安定的な提供の確保

• 国家関与が疑われるサイバー攻撃事案が多発
• 規制対象となる事業者に対して、対応策を審査して、勧告や指導が行われるようにするもの
• 法定14事業から、特定社会基盤役務の提供を行うものを政令で指定して、個別の事業者を指定する
  • 特定社会基盤事業者の指定基準は、有識者会議で議論されている
  • 大きい事業者が念頭に置かれている
• 導入や維持管理について、審査を受けることになる

特定重要設備とは

• 機器やプログラムが含まれる
• クラウドプログラムも含ま得る
• 計画書に記載した機能に関係する追加・変更を行う場合に届け出や報告が必要

審査の流れ

• 事業所菅大臣宛てに導入計画書を提出して、事業所管省庁が審査
  • 特定妨害行為の手段として使用される恐れが大きいかを審査
    • 恐れが大きい場合、必要な措置を講じるか、中止するかの勧告がなされる
  • 導入計画書には、法定記載事項が定義されている
    • 関わる人間の国籍や外国政府とのつながり、役員の国籍
  • 審査の考慮要素
    • 脆弱性も審査されるが、供給者等の属性が中心
    • 慎重な審査対象
      • 日本の外部にある主体から強い影響を受けている事業者
      • 経済制裁措置を執っている対象から強い影響を受けている事業者
      • 日本や同盟国に害をなす行為を行っている主体に関係があるか

審査後

• 来年春以降より運用開始
  • 遡及適用はされない
• 継続的なリスク管理が必要

企業に何が求められるか？

• これまでの監督行政対応とは異なる視点が必要
• 従来のリスク管理体制に加えた体制整備や経営陣の関与も必要
• まずは現時点でのルールに理解からスタート
• 導入委託プロジェクトへのリスク管理部門の関与
• リスク管理に法務担当者の関与が必要
• 規制対応をスケジュールに組み込んで対応をしていく

---

幕間1

AWSが提供するセキュリティ・アイデンティティ管理の機能

• Amazon Security Lake（プレビュー）
• ログデータをデータレイクに集めて、様々なツールで分析する

AWSのDigital統制に関する顧客との約束

• 企画・設計段階から統制
  • 暗号化、IAMとControlTowerとモニタリングとログ記録
  • データ統制の実現
  • データの保管場所の管理
  • 検証環境
• 透明性と保証による信頼の獲得
  • 手続きによる対応
    • 米国政府からのデータ開示要請があったとしても、易々と応じない仕組み
• ガバメントクラウド
  • デジタル庁が共通的な基盤を用意していく

---

ガバメントクラウドでのセキュリティの考え方～範囲の絞り込みと日々の監視・修正

デジタル庁
シニアエキスパート（クラウドコンピューティング）
山本 教仁 氏

NISTなどのフレームワークに準拠しつつ進めてる

• 二本柱
  • 管理する側のガバナンス
  • 利用するシステムに対するセキュリティ機能の強制と実装や運用のベストプラクティスの提供
• 外観
  • 1府2庁11省（680以上のシステム）
  • 国民がユーザー
• スケラビリティと大規模な展開
  • なるべくクラウドの機能をそのまま使う
• ガードレールによる自動化
  • ゲートキーパー方式による技術バナンスの実現
  • ガードレール方式による技術バナンスの実現

スケールとガバナンスの両立

• 分散環境でのガバナンスの自動化
  • セキュリティポリシーをテンプレート化
  • 共通設定内容をテンプレート化、自動化
    • ネットワークやOS、ミドルウェア、フレームワークまではIaCテンプレートで対応
  • 予防的。発見的統制による監視
    • クラウドサービス事業者が提供している機能を積極的に利用
  • ダッシュボードによる可視化
    • テンプレートを用意して提供している

利用システムをどう守るか

• 責任共有モデルに基づいて、対応する領域を絞っていく
• 利用者の責任の部分を確認
  • 環境へアクセスするデバイスや通信
  • サービスの設定
  • 外部から許可した通信とそれを受け付けるプログラム
• 日常的な監視で対応
  • 設計方針（責任共有モデルで範囲を絞り込み）
    • マネージドサービスを使う
    • OSを稼働させない
    • 外部通信を絞る(HTTPSのみに絞る)
  • セキュリティ対策
    • WAF
    • サーバーレスなら、OSの管理やアンチマルウェアは要らない
    • 重要なのはアプリケーションやインフラリリースのセキュリティ（CI/CD）
    • システム構成が意図したとおりか常に確認
      • CISベンチマークやベストプラクティスの自動チェック
        • NIST SP800-53の自動検出もでた
      • 構成変更ルール違反自動検出
      • AIに夜不正自動検出
  • 運用
    • 重大になる前に日々の改善活動
      • ダッシュボードで対応状況を可視化する
      • チャット通知

ガバメントクラウドでの実践例

• IaCでアプリとインフラ構成の自動化するCI/CD環境を構築
  • すべてマネジメントサービスで構成
  • EC2なし
• ChatOpsのSlackチャンネルにSecurity HubたConfig RuleのAlertをリアルタイムで通知
• CloudWatchダッシュボードで一日の登録数など業務的なメトリクスも表示
  • ダッシュボードの設計が特に大事。KPIを効果的に表示するように設計している。

---

幕間2

• セキュリティは、すべての組織活動で不可欠になる
• ダイバーシティの考慮で、セキュリティ人材のギャップに対象
• AIで自動化

---

クラウドリスク管理の進展、金融業界における教訓と、現時点で責任者が認識すべきこと

有限責任監査法人トーマツ
リスクアドバイザリー事業本部 アシュアランス マネージングディレクター
片寄 早百合 氏

金融庁が出したレポートでは、3年前のクラウド利用率は86%
クラウド利用に対する懸念

• 機密性
• 可用性
• 監査受入体制
• データ所在地

金融機関とクラウドサービスの出会い

• 最初は利用契約だった
  • フレキシブルに利用できる
  • 設備投資が不要
  • 新しいサービスのテストに使える
  • データ分析がしたい
• 外部委託先管理やデータの保管場所が問題だった

重要インフラとして求められるもの

• 金融監督指針やFISC安全対策基準などで、高い信頼性とセキュリティが求められている
• システムリスクとして、顧客の重要情報を網羅的に洗い出して、把握、管理しているかは外部委託管理の範囲内であった
  • 関係者とあるべき姿について粘り強く検討した
    • 議論と交渉を重ねて、クラウドサービス事業者も対応した
      • 監査報告書、SOC2レポート、認証情報の開示、マルチリーじぇおん、FISC安全対策へのリファレンス公開
    • FISC側もガイドラインを提示した

クラウドサービス利用者側によるリスク管理

• 責任共有モデルを正しく理解した上で、利用者自身で責任を担うためのガバナンス整備とリスク管理をする必要がある
  • サービスの適用範囲によって責任の範囲は、組み合わせによって変わる
  • 従来の社内規定で充足できない事が出てくる可能性がある
  • セキュリティ管理について、クラウド利用に係わる知識や経験が必要となる

クラウドサービス利用者側によるリスク管理(課題)

• 想定外のランニングコスト
  • 利用状況の分析と、コスト削減のための設定変更やしくみ導入で対応

クラウドサービス利用者側によるリスク管理(種類)

• アプリケーション
  • 設計と変更管理、設計とアーキテクチャ,製造とテスト
• インフラ
  • ネットワーク構成におけるリスクを識別して多層防御にて対応する
• ガバナンス
  • セキュリティのレギュレーション準拠の確認を、クラウドベンダーが用意しているツールを有効化して発見、通知、対処のプロセスの自動化
• データ管理
  • 用途に応じたクラウドサービスのストレージに格納してコスト最適化
• 回復性
  • パイロットライトアプローチの手法が適用されているか
• 監視
  • クラウドベンダーが用意している仕組みに必要な情報を集約して、監視システム自体の信頼性を確保
• アクセス管理
  - クラウドベンダーが用意するポリシーを利用する

まとめ

• 自分たちで整備して、最終的に管理できるようにしていく事が必要

---

100ヶ国＆50万顧客に支持されるセキュリティプラットフォーマーが描くAWSセキュリティのデザイン

トレンドマイクロ株式会社
ビジネスマーケティング本部 クラウドビジネス&アライアンスグループ グループ長 シニアマネージャー
福田 俊介 氏

サイバーセキュリティはどうあるべきか

• リスクを正しく理解して、受容可能なレベルまで下げる事がリスクマネジメントの目標
  • リスク＝脅威ｘ脆弱性ｘ資産

サイバーセキュリティの現状

• かつてないほどセキュリティの基本が困難な時代。セキュリティチームは疲弊している
• 大量のデバイスやサービス、野良SaaS、大量のAlert
• 平均21種類のセキュリティツールの利用

理想型は、SOC/CSIRTによるセキュリティオペレーションの統合

• クラウドもこれに含むべきである

インシデントレスポンスの事例

• クラウド上のサーバーのメンテナンスポートを閉じ忘れた
• ステークホルダーが多く、複数のセキュリティポリシーを持っていた
• どこからでも弄れるという利便性が裏目に出た

全部やるには

• Trend Vision Oneのセキュリティオペレーションプラットフォーム
  • 組織に所属する個人のリスクの可視化とスコアリング
  • 攻撃面の可視化とスコアリング
  • 利用サービスの可視化とスコアリング
  • XDR
    • PCだけを見ていても足りない
    • クラウドなどのIT資産を一元的に見る必要がある
• Alertで疲弊するんじゃないの？
  • 重要度や緊急度を表示して、対応を要するものに絞って対応できる

クラウドセキュリティはどうあるべきか

• サービスによって責任範囲が異なる
  • 一つのツールでやりきるには無理がある

事例

• s3にCloud One ファイルストレージセキュリティを導入した
  • 利用者のスマホなどで撮影した画像を格納するサービス
  • 格納されたコンテンツに対するウィルススキャンを行った

おわりに

• クラウドもITの一部と捉えて、対応をしてください
• セキュリティをツールとして選ぶ時代は終わった
  • セキュリティもプラットフォームへの時代
• クラウドセキュリティをITセキュリティオペレーションの一部にしてほしい
  • クラウド・オンプレで役割を分ける時代は終わった

---

Amazon GuardDutyを活用した脅威検知・通知サービスのご紹介

株式会社日立システムズ
セキュリティ販売推進部 担当部長
松本 芳宏 氏

GuardDutyの活用状況と課題

• 実装済みは20%
  • プレゼンスが低い
  • 動かしているだけでは、検知したことを把握できない
  • EmailやSNS通知できるけど、内容がわかりにくい

MSSを立ち上げた

• メッセージを構造化して、わかりやすいように整形した
• 属人的になりがちな部分を自動化した
  • これまでのSOCノウハウとMitre ATT&CKで分類
  • CSFの防御・対応に使える情報を提供できるようにした
• Radware Cloud Native Protector
  • CSPM/CIEM
  • CTDR(インシデントレスポンス)

まとめ

• AWSセキュリティ対策にベストプラクティス例
  • 識別
    • CSPM/CIEM
    • Radware CNP
  • 防御
    • ベストプラクティスアセスメントサービス
    • ベストプラクティスチェック・設計
  • 検知
    • セキュリティ監視サービス
  • 対応・復旧
    • Radware CNP
      • フォレンジック支援

---

AWSを使った医療機関等におけるランサムウェア対策

アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 ヘルスケア担当 ソリューション アーキテクト
片山 洋平 氏

好きなAWSサービス：Amazon Health Lake
ガイドラインそのものには言及しない

ヘルスケア領域におけるランサムウェア脅威の現状

• LockerやCrypto
• 身代金の支払いは、回復の保証はなく、攻撃者の助長となるので決して行ってはいけない
• 脆弱性も審査されるが、供給者等の属性が中心
• 診療報酬改定、医療法、ガイドラインにバックアップ体制や管理状況が挙げられている

医療情報を扱うシステムのガイドライン

• 患者、医療機関、情報システムサービスの提供者が登場人物
• ガイドラインは、医療機関、情報システムサービスの提供者が準拠すべき要求事項が記載されている
  • 最低限の対策と推奨される対策が記載されている
  • 是非、平時から確認してほしい

電子保存の要求事項3基準

• 真正性
• 見読性
• 保存性
  • 真正性と見読性を維持した状態で保存する

医療情報システムにおける責任共有モデル

• 医療機関、委託事業者、AWSそれぞれの責任範囲が定められている
• AWSからは、ランサムウェアからAWS環境を保護するe-bookが掲載されている
  • NIST CSFに則っている
  • 復旧の手段について選択肢が少なく、軽視されてきた
    • ここを重点的に考えてほしい

復旧における2つの重要な指標

• RPOとRTO

災害復旧とランサムからの復旧の違い

• 災害復旧はデータがある
• ランサムは、データが正しいかどうかの保証がポイント
  • 論理的なエアギャップを構成する必要がある

ランサムからの復旧戦略の策定

• 時間と費用はトレードオフ
• 現在のバックアップ戦略を確認して、整理する事がお勧め

従来のバックアップ戦略

• 論理的なエアギャップが考慮されていない
• データのスケールによる費用対効果に対する疑問
• リカバリの検証に対する疑問

S3とAvailability Zone

• 改ざん防止機能としてのObject Lock
• ストレージクラスによってコスト効果を上げることができる
  • RTOやRPOを鑑みながら選択する必要がある
• ライフサイクル機能

AWS Backup

• イミュータブルなバックアップ
  • Vault Lockでrootユーザーでも削除禁止にできる（コンプライアンスモード）
• オンプレミス（VMWare）にも対応している

バックアップとリストア、モニタリング

バックアップ

• s3 Object lockとAWS Backupで論理的なエアギャップを作る

リストア

• 医療情報システム等の障害発生時の対応フローチャート
  • ガイドラインに掲載されている
• 医療機関内での復旧が不可の場合、委託先業者による復旧にシフトする
  • クラウドにBC環境を構築する
    • Amazon AppStream2.0やWorkspacesでの業務環境を用意して、停止しておく
    • IaCを使う事で、煩雑な手順を簡略化する

モニタリング

• ログの管理とモニタリング
  • CloudTrail
  • CloudWatch
  • AWS Config
  • VPCフローログ
  • GuardDuty

---

おわりに

オフラインイベントの熱量を感じる会でした！
今後もオフラインイベントは増えていくと思うので、どんどん参加していきたいと思います。
実はひろかず自身もパネルディスカッションのパネラーとして登壇しています。
詳しい内容は、アーカイブが出たらチェックしてほしいです！

今日はここまでです。
お疲れ様でした。