第83回 雲勉【オンライン：中級者向け】 クラウド環境のセキュリティリスクアセスメントと その対応

０．講師自己紹介 2 ■ 村上 桃子 ≫ クラウドインテグレーション事業部 セキュリティセクション セキュリティサービスの提供、サービス立ち上げなどを行っています ≫ 2021年 6月入社 ≫ 最近 音声コンテンツ (Podcast, Audible, etc.) を聴きすぎて耳が痛い (良いイヤホンを探しています)

アジェンダ 3 0. 自己紹介 1. あなたのクラウド環境、安全ですか？ 2. リスクアセスメントとは 3. クラウド環境のリスクを可視化してみよう 4. リスクへの対応を検討してみよう 5. AWS Well-Architected Framework のご紹介 6. おわりに 7. 質疑応答 (19:50~20:00)

1. あなたのクラウド環境、安全ですか？ 4

安全な環境とは 5 100% 安全な環境は作れるでしょうか？

安全な環境とは 6 100% 安全な環境は作れるでしょうか？

身近なもので安全を考えてみる 7 住んでいる人や家財が 100% 安全な家は作れるでしょうか？ 泥棒が入れない 自然災害の被害を受けない etc. 想定できるリスクに全て対応すれば、安全...？ 治安の良い 自然災害の被害を受けない土地に 防犯対策が完璧で、 外壁や開口部の強度が十分な家を建てる？

身近なもので安全を考えてみる 8 リスクは他にもあります 家の中で怪我をするリスク 家財を壊してしまうリスク 招き入れた客が悪さをリスク … 全部のリスクに対応するとしたら 内壁や家財を超柔らかい素材にして 窓を全部なくして 誰も家に呼ばない 人間的な生活ですか？

100% 安全にすることはできません リスクが許容できる範囲であること が重要 身近なもので安全を考えてみる 9 生活費 怪我・病気の治療費 家財の価値 安全にするための 労力・費用

クラウド環境の安全を考える 10 100%安全なクラウド環境は作れますか？ 開発者・運用者による データ持ち出し セキュリティサービスの設 定ミス クレデンシャル漏えい バックアップ不足

クラウド環境の安全を考える 11 クラウドを活用してビジネスやサービスの目的を達成するために、 どれくらい安全なら許容できますか？ システム停止時の 機会損失 データの重要性 お客様の信頼 セキュリティに かけるコスト

リスクとコストのバランスを考える 12 どんな対策を行えば、 効率よくリスクを小さくしてシステムを安全にできるでしょうか？ → リスクアセスメント　という手法があります

2. リスクアセスメントとは 13

リスクとは 14 　もう少し噛み砕くと ... 　事象の 起こりやすさ × 影響 100年に一度　一回の損害１億円 1年に一度　　一回の損害１億円 1年に一度　　一回の損害５億円 リスク 大 リスク = 目的に対する不確かさの影響 (リスクマネジメントの国際規格 ISO31000) TIPS リスクには、損害が発生する悪いリスク以外に、利益が発生する 良いリスクもあります。 今回は悪いリスクを扱います。

リスクアセスメントとは 15 ■ どんなリスクがあるか洗い出し ■ 起こりやすさ・影響を分析し ■ リスクへの対応方法を検討し、対応の優先順位付けをする 一連のプロセス・手法のこと リスクアセスメント前 リスクアセスメント後 リスク リスク リスク リスク リスク リスク リスク リスク リスク リスク 未知のリスク 対応する 対応しない

■ どんなリスクがあるか洗い出す ≫ 火事、大地震、窃盗、自損事故、 etc. ■ 起こりやすさ・影響を分析する ≫ 起こりやすさ：自損事故 > 火事 > 盗難 >> 大地震 ≫ 影響度：　　　大地震 > 火事 > 盗難 ~ 自損事故 ≫ リスク：　　　火事 > 自損事故 > 盗難 > 大地震 ■ リスクへの対応方法を検討する ≫ 火災報知器、防犯対策、耐震設計、 保険に入る、体を鍛える、etc. 身近なものでリスクアセスメントを考えてみる 16 ※ イメージしやすいように簡略化しています。

3. クラウド環境のリスクを可視化してみよう 17

今回のアセスメントのスコープ 18 右図のようなクラウド環境で 運用予定のサービス、および、 それに関わる情報 サービス概要 • 会員制サイト • 一般利用者は 登録時に実名、 生年月日が必要 • 運営者、一般利用者ともに 記事投稿、コメントなどが可能 運用体制 • 小規模な会社で運営 • システム開発・保守を外部委託 • コンテンツ運営は自社で実施

● ステークホルダー ● システム ● 業務プロセス などの観点から、 発生すると機密性・完全性・可用性に悪影響がある事象を洗い出します。 リスクの洗い出し方 19 TIPS システムが保有している情報や構成が把握できていない、誰が関わるシステムか分からない、 という場合は、まず先にそちらを整理しましょう。 (※今回は資産整理方法は割愛します ) TIPS アセスメント対象のステークホルダーにも、アセスメントに参加してもらいましょう。 外部の専門家では見つけられないリスクもあります。

洗い出したリスク例 20 ● ステークホルダー関連 ○ 退職者が不正にリソースやデータにアクセスする ○ 会員ID・パスワードが不正利用される ○ etc. ● システム関連 ○ パブリック公開設定のリソースが攻撃を受ける ○ AWS アカウントのルートユーザーが乗っ取られる ○ 開発・保守用のIAM ユーザーが乗っ取られる ○ コンテンツ管理用のユーザーが乗っ取られる ○ Web サーバーに不正にリモートログインされる ○ 個人情報を含む通信が盗聴される ○ AWS の障害によりサービス提供ができなくなる ○ 脆弱性を悪用される ○ 不適切なキャッシュ設定により情報が漏えいする ○ ログが取得されておらず、障害の原因を特定できない ○ etc. ● 業務プロセス関連 ○ 開発・保守中の誤操作でリソースやデータが削除される ○ クレデンシャルが公開リポジトリにアップロードされる ○ 誤ったコンテンツを投稿してしまう ○ etc. TIPS セキュリティガイドラインなどを参考に 一般的なリスクを洗い出し、 アセスメント対象に特有のリスクを 追加で列挙すると効率的です。 これはリスク？と迷ったら、 ひとまず書いておく。

洗い出したリスクを分析する 21 どのような原因で、どのような結果になるか具体的に検討し、 リスクを比較できるように、指標を使って分析します。 攻撃頻度 心理的抵抗 必要な権限 機密性への影響 完全性への影響 可用性への影響 リスク 起こりやすさ 影響 各項目 3段階評価し合計 (3 ~ 9点) 各項目 3段階評価し合計 (3 ~ 9点) 9 ~ 81 点 TIPS 上記の分析方法、指標は一例です。 また、起こりやすさや影響は、組織や環境によって異なります。 発生頻度と損害額を具体的に数値化して比較する場合もあります。 今回は具体的な数値化までは行わず、相対的に比較できるようにしています。

リスク分析後のリスク一覧の例 22 リスク 原因 具体的な影響 起こりやすさ 影響 攻撃頻度 心理的抵抗 必要な権限 可用性 完全性 機密性 退職者が不正にAWS アカウントにアクセスする 退職者による 不正操作 データ・リソースが消失してサー ビス継続できなくなる 1.毎年一度 未満 1.大 (犯意 あり) 2.管理者 3.長期停止 3.全情報 1.ほとんど 無し パブリック公開設定の リソースが攻撃を受ける 外部からの攻 撃 会員情報が流出する 3.毎月一回 以上 1.大 (犯意 あり) 3.一般利用 者 / 権限な し 3.長期停止 1.ほとんど 無し 3.重要機密 情報・個人 情報 ルートユーザーが 乗っ取られる 外部からの不 正ログイン 会員情報が流出する 2.毎年数回 1.大 (犯意 あり) 3.一般利用 者 / 権限な し 3.長期停止 1.ほとんど 無し 3.重要機密 情報・個人 情報 ルートユーザーが 乗っ取られる 外部からの不 正ログイン リソース・データが消失する 2.毎年数回 1.大 (犯意 あり) 3.一般利用 者 / 権限な し 3.長期停止 3.全情報 1.ほとんど 無し AWSのリージョン障害によ り、Webサービスが利用でき なくなる AWS障害 サービス提供ができない 1.毎年一度 未満 1.大 (犯意 あり) 2.管理者 2.数日停止 1.ほとんど 無し 1.ほとんど 無し 脆弱性を悪用される 外部からの攻 撃 会員情報が漏えいし信頼が低下 する 3.毎月一回 以上 1.大 (犯意 あり) 3.一般利用 者 / 権限な し 3.長期停止 1.ほとんど 無し 3.重要機密 情報・個人 情報 誤操作でリソース・ データを削除する 開発・保守中 の作業ミス データ・リソースが消失してサー ビス継続できなくなる 1.毎年一度 未満 2.中 (注意 喚起あり) 2.管理者 3.長期停止 3.全情報 1.ほとんど 無し

4. リスクへの対応を検討してみよう 23

リスクを順位付けする 24 リスク 原因 具体的な影響 起こりやすさ 影響度 起こりやすさ× 影響度 パブリック公開設定のリソースが 攻撃を受ける 外部からの攻撃 会員情報が流出する 7 7 49 脆弱性を悪用される 外部からの攻撃 会員情報が漏えいし 信頼が低下する 7 7 49 ルートユーザーが乗っ取られる 外部からの不正ログイン 会員情報が流出する 6 7 42 ルートユーザーが乗っ取られる 外部からの不正ログイン リソース・データが消 失する 6 7 42 誤操作でリソース・データを削除する 開発・保守中の作業ミス サービス継続できなく なる 5 7 35 退職者が不正にAWSアカウントに アクセスする 退職者による不正操作 データ・リソースが消 失してサービス継続で きなくなる 4 7 28 管理者ユーザーアカウントが乗っ取られる 外部からの不正ログイン コンテンツが改ざん・ 削除される 6 4 24 AWSのリージョン障害により、 Webサービスが利用できなくなる AWS障害 サービス提供ができな い 4 4 16 リスク 大

リスクへの対応方法 25 リスクを回避する リスクを生じる活動を実施しない。 (例) 個人情報を収集しない リスクを取る 利益追求のためリスクを増加させる。 (例) 投資を増やす リスク源を除去する リスク要因を取り除く。 (例) 運用を自動化する 起こりやすさを変える 発生頻度を下げる対策を行う。 (例) 侵入を防御する 結果を変える リスクを生じる事象が発生しても、 影響が小さくなるようにする。 (例) 侵入を検知・通知する リスクを共有する リスクを他者と共有する。 (例) 保険に入る リスクを保有する リスクを許容し、対策を行わない。 (例) ダウンタイムを許容する

リスクへの対応を考えてみる 26 起こりやすさ × 影響度が大きいもの リスク 原因 具体的な影響 起こりや すさ 影響度 起こりや すさ×影響 度 管理策 詳細 パブリック公開設定のリソースが攻撃 を受ける 外部からの 攻撃 会員情報が流出する 7 7 49 起こりやすさを 変える 公開設定のバケットを検知し、通 知する。 脆弱性を悪用される 外部からの 攻撃 会員情報が漏えいし信 頼が低下する 7 7 49 起こりやすさを 変える WAFでWebアプリを保護する。 ルートユーザーが乗っ取られる 外部からの 不正ログイ ン 会員情報が流出する 6 7 42 起こりやすさを 変える MFA を設定し、MFA デバイスを 適切に管理する ルートユーザーが乗っ取られる 外部からの 不正ログイ ン リソース・データが消失 する 6 7 42 結果を変える ルートユーザーの異常なふるまい を検知し通知する リスク回避 も考えられる (個人情報を収集しない )

リスクへの対応方法を考える 27 起こりやすさ × 影響度が小さいもの TIPS 具体的な金額を使って、 (対応しなかった場合のリスク − 対応にかかるコスト) と 対応後のリスク を比較して、更に細かく優先順位をつける方法もあります。 リスク 原因 具体的な影響 起こりやすさ 影響度 起こりやすさ ×影響度 管理策 AWSのリージョン障害により、 Webサービスが 利用できなくなる AWS障害 サービス提供ができない 4 4 16 リスクを保有する

ここまでのまとめ 28 ① 安全なクラウド環境とは何か考えました ② リスクとリスクアセスメントについて紹介しました ③ リスクを洗い出し、起こりやすさ・影響を分析しました ④ リスクを順位付けし、対応方法を検討しました あとは、合意を取って、対応を完了させるだけで OK ？

継続的なリスクアセスメントのすゝめ 29 ■ ビジネスや環境の変化 ■ 新しいリスクの顕在化 ■ 起こりやすさ・影響の変化 ■ リスク対応方法の見直し → 継続的なリスクアセスメントを！

リスクの洗い出しとか、分析とか、大変そう 30 …という方へ！ AWS 環境のリスクアセスメントに使えるベストプラクティス集と、 ツールがあります。

5. AWS Well-Architected Framework のご紹介 31

Well-Architected Framework とは 32 システム設計・運用のベストプラクティス集 Well-Architected Review の流れ 1. W-A Framework に沿って、 ベストプラクティスに則っているか現状をレビュー 2. リスクを把握 (リスク ≒ ベストプラクティスに沿っていない部分) 3. 改善策を検討し優先順位付けをする 運用の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 サステナビリティ リスクを 1 から 洗い出さなくて良い W-A Tool を使えば リスクレベルも提示され、優 先度がわかる

アセスメント方法の選び方 33 こんな環境なら リスクアセスメントをどう進めますか？ https://iret.media/62149

5. おわりに 34

おわりに 35 リスクアセスメントを行い、リスクを分析して対応の優先順位付けをすることで、 効率よくセキュリティ対策を行うことができます。 リスクアセスメントや Well-Architected Review には 多少時間がかかりますが、 行き当たりばったりの対策や、不可能な「100%の安全」を目指すよりも、 効果的です。 現在運用しているシステムや、 これから構築するシステムで実施してみてはいかがでしょうか？

6. 質疑応答 36