Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Y.Sumikura
September 09, 2022

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

Y.Sumikura

September 09, 2022
Tweet

More Decks by Y.Sumikura

Other Decks in Technology

Transcript

  1. アジェンダ 3 0. 自己紹介 1. あなたのクラウド環境、安全ですか? 2. リスクアセスメントとは 3. クラウド環境のリスクを可視化してみよう

    4. リスクへの対応を検討してみよう 5. AWS Well-Architected Framework のご紹介 6. おわりに 7. 質疑応答 (19:50~20:00)
  2. リスクとは 14  もう少し噛み砕くと ...  事象の 起こりやすさ × 影響 100年に一度 一回の損害1億円 1年に一度  一回の損害1億円

    1年に一度  一回の損害5億円 リスク 大 リスク = 目的に対する不確かさの影響 (リスクマネジメントの国際規格 ISO31000) TIPS リスクには、損害が発生する悪いリスク以外に、利益が発生する 良いリスクもあります。 今回は悪いリスクを扱います。
  3. ▪ どんなリスクがあるか洗い出す ≫ 火事、大地震、窃盗、自損事故、 etc. ▪ 起こりやすさ・影響を分析する ≫ 起こりやすさ:自損事故 >

    火事 > 盗難 >> 大地震 ≫ 影響度:   大地震 > 火事 > 盗難 ~ 自損事故 ≫ リスク:   火事 > 自損事故 > 盗難 > 大地震 ▪ リスクへの対応方法を検討する ≫ 火災報知器、防犯対策、耐震設計、 保険に入る、体を鍛える、etc. 身近なものでリスクアセスメントを考えてみる 16 ※ イメージしやすいように簡略化しています。
  4. 今回のアセスメントのスコープ 18 右図のようなクラウド環境で 運用予定のサービス、および、 それに関わる情報 サービス概要 • 会員制サイト • 一般利用者は

    登録時に実名、 生年月日が必要 • 運営者、一般利用者ともに 記事投稿、コメントなどが可能 運用体制 • 小規模な会社で運営 • システム開発・保守を外部委託 • コンテンツ運営は自社で実施
  5. • ステークホルダー • システム • 業務プロセス などの観点から、 発生すると機密性・完全性・可用性に悪影響がある事象を洗い出します。 リスクの洗い出し方 19

    TIPS システムが保有している情報や構成が把握できていない、誰が関わるシステムか分からない、 という場合は、まず先にそちらを整理しましょう。 (※今回は資産整理方法は割愛します ) TIPS アセスメント対象のステークホルダーにも、アセスメントに参加してもらいましょう。 外部の専門家では見つけられないリスクもあります。
  6. 洗い出したリスク例 20 • ステークホルダー関連 ◦ 退職者が不正にリソースやデータにアクセスする ◦ 会員ID・パスワードが不正利用される ◦ etc.

    • システム関連 ◦ パブリック公開設定のリソースが攻撃を受ける ◦ AWS アカウントのルートユーザーが乗っ取られる ◦ 開発・保守用のIAM ユーザーが乗っ取られる ◦ コンテンツ管理用のユーザーが乗っ取られる ◦ Web サーバーに不正にリモートログインされる ◦ 個人情報を含む通信が盗聴される ◦ AWS の障害によりサービス提供ができなくなる ◦ 脆弱性を悪用される ◦ 不適切なキャッシュ設定により情報が漏えいする ◦ ログが取得されておらず、障害の原因を特定できない ◦ etc. • 業務プロセス関連 ◦ 開発・保守中の誤操作でリソースやデータが削除される ◦ クレデンシャルが公開リポジトリにアップロードされる ◦ 誤ったコンテンツを投稿してしまう ◦ etc. TIPS セキュリティガイドラインなどを参考に 一般的なリスクを洗い出し、 アセスメント対象に特有のリスクを 追加で列挙すると効率的です。 これはリスク?と迷ったら、 ひとまず書いておく。
  7. 洗い出したリスクを分析する 21 どのような原因で、どのような結果になるか具体的に検討し、 リスクを比較できるように、指標を使って分析します。 攻撃頻度 心理的抵抗 必要な権限 機密性への影響 完全性への影響 可用性への影響

    リスク 起こりやすさ 影響 各項目 3段階評価し合計 (3 ~ 9点) 各項目 3段階評価し合計 (3 ~ 9点) 9 ~ 81 点 TIPS 上記の分析方法、指標は一例です。 また、起こりやすさや影響は、組織や環境によって異なります。 発生頻度と損害額を具体的に数値化して比較する場合もあります。 今回は具体的な数値化までは行わず、相対的に比較できるようにしています。
  8. リスク分析後のリスク一覧の例 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.ほとんど 無し
  9. リスクを順位付けする 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 リスク 大
  10. リスクへの対応方法 25 リスクを回避する リスクを生じる活動を実施しない。 (例) 個人情報を収集しない リスクを取る 利益追求のためリスクを増加させる。 (例) 投資を増やす

    リスク源を除去する リスク要因を取り除く。 (例) 運用を自動化する 起こりやすさを変える 発生頻度を下げる対策を行う。 (例) 侵入を防御する 結果を変える リスクを生じる事象が発生しても、 影響が小さくなるようにする。 (例) 侵入を検知・通知する リスクを共有する リスクを他者と共有する。 (例) 保険に入る リスクを保有する リスクを許容し、対策を行わない。 (例) ダウンタイムを許容する
  11. リスクへの対応を考えてみる 26 起こりやすさ × 影響度が大きいもの リスク 原因 具体的な影響 起こりや すさ

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

    と 対応後のリスク を比較して、更に細かく優先順位をつける方法もあります。 リスク 原因 具体的な影響 起こりやすさ 影響度 起こりやすさ ×影響度 管理策 AWSのリージョン障害により、 Webサービスが 利用できなくなる AWS障害 サービス提供ができない 4 4 16 リスクを保有する
  13. Well-Architected Framework とは 32 システム設計・運用のベストプラクティス集 Well-Architected Review の流れ 1. W-A

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