クラウド移行で改善するガバナンスファーストの障害対策

こんにちは。次世代システム研究室のT.Tです。

2024年9月24日に行われた社内の研究発表会の内容をご紹介します。現在開発運用に携わっているサービスのシステム基盤のAWSへの移行を検証しています。常時稼働が求められるサービスのため、障害発生の防止や障害が発生した場合でも早期の復旧が求められます。AWSへの移行に伴い、運用中のオンプレ環境では改善が難しかった障害対応の対策にも取り組んでいます。

研究発表では、過去に発生した障害事例のご紹介とAWS移行に伴い実施した過去の障害事例への対策を通じて、サービス運用の初期段階でITガバナンスの視点を取り入れて、障害対策の改善を試みた事例についてご紹介しました。発表資料は公開してありますので、以下からご覧いただけます。

スライドの概要

1.モチベーション

運用しているWebサービスの概要

• ログイン機能は常に使える必要あり
• メールアドレスや住所等の個人情報を扱っている

サービスでは常時稼働が求められるため、障害が発生しないための対策がまずは必要になりますが、こうした対策を講じていても障害を完全に無くせないという実情があります。そのため、障害が発生した際には再発防止策という形で対策を行いますが、これまでの障害対策アプローチではオンプレ環境による制約が多く、恒久対策が実施出来ないケースが発生する傾向が増えていました。</>

理想的な障害再発防止対策

1. 障害が発生
2. 原因調査/障害復旧
3. 根本原因調査
4. 恒久対策検討
5. 恒久対策実施

実際の障害再発防止対策

1. 障害が発生
2. 原因調査/障害復旧
3. 根本原因調査
4. 恒久対策検討
5. 恒久対策出来ない(システムの大きな改修が必要なため)
6. 次善の対策実施

そのような経緯で、再発防止策を導入して障害の発生を抑えることに繋げられていますが、次善の対策で解決している部分もあり、オンプレ環境ではまだ課題として残存している部分もあります。

これまでの対策による改善例

• サービス監視で見落としていた項目の追加
• 開発とビジネス責任者の両方の承認を受けてから本番環境にリリースする
• リスト型攻撃を受けた時に調査対象のログと対応フローの整理

オンプレ環境で残存している課題

• リリース前の承認確認は人力で対応している
  • 承認されていなくてもリリーススクリプトが実行出来る
  • 新しいメンバーがリリースを担当する時にインシデントが発生する
• リスト型攻撃を受けた時の調査コストが高い
• システム内部に不正侵入された時の検知システムが弱い
  • 不正侵入の経路を防ぐ対策は実施している
  • さらに不正侵入された時の対策も強化しておきたい

また、別の問題として現在システムが稼働している環境のシステム老朽化があり、その対策として稼働環境をオンプレからAWSへの移行する計画が立ち上がりました。その移行に伴う調査に合わせて、残存課題の解決も検討しました。その結果として、AWSのガバナンス機能で残存課題の解決が出来そうな見通しが立ったため、ガバナンス機能を初期段階で導入することで、ガバナンス強化対策を設計段階に組み込み、障害防止対策等を行いました。今回の取り組みのモチベーションをまとめる次のようになります。

モチベーション

• サービス根本改善
  • サービス運用にガバナンス視点を積極的に導入して、サービスの障害発生防止、障害発生時の原因究明と再発防止を簡易化したい
• チャンス
  • 稼働環境をオンプレからAWSに移行する機会に合わせて導入したい
• 開発者メリット
  • 開発運用の担当者が本来業務に専念出来るようにしたい

2.Webサービスのガバナンスとは

自分の中ではガバナンスを漠然としたイメージで捉えていたところがあったので、今回改めてどのようなものか調べてみました。ガバナンスといって最初に思い浮かべたのはコーポレートガバナンスだったので、そちらを最初に調べてみました。以下の内容になります。

コーポレートガバナンスとは

• 企業が健全な経営を維持し透明性と説明責任を果たす仕組み
• 2000年初頭のエンロン社やワールドコム社の不正会計をきっかけに浸透

コーポレートガバナンスの内容はWebサービスに適用する考え方としてはギャップがありました。他にITガバナンスというものがあったので、そちらを調べてみるとWebサービスに適用出来そうな考え方ということが分かりました。こちらは以下のような内容になります。

ITガバナンスとは

ITガバナンスとは、組織体のガバナンスの構成要素で、取締役会等がステークホルダーのニーズに基づき、組織体の価値及び組織体への信頼を向上させるために、組織体におけるITシステムの利活用のあるべき姿を示すIT戦略と方針の策定及びその実現のための活動である。

https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf

ITガバナンスは2002年にみずほ銀行のシステム統合における大規模なシステム障害以降注目を集めるようになったようです。この定義は少し難しいですが、内容としてはサービス運用のベストプラクティスと言えるものになっています。

ガバナンス不足による直近のインシデント事例

ITガバナンスの導入が進められる発端となった事例は20年以上前で、最近では状況も変わってきています。直近発生したインシデント事例を確認してみます。

• KADOKAWA、サイバー攻撃で特損36億円　補償・復旧に
• DMMビットコイン482億円流出､金融庁は原因究明求める

https://www.nikkei.com/article/DGXZQOUC1472H0U4A810C2000000/
https://www.nikkei.com/article/DGXZQOUB31BF90R30C24A5000000/

こういった事例を踏まえると、開発プロセスの改善に加えて、外部からの脅威に対する対策も必要ということが見えてきます。ITガバナンスでは次の8つの要素から成っていて、この内運用体系の構築、ガイドラインの設定と遵守、リスク管理がWebサービスのガバナンスとして有効な要素になっています。

ITガバナンスに必要な8つの構成要素

• 戦略と情報システムの整合性
• 組織体制の確認・改善
• 業務内容の把握
• コストの算出・費用対効果
• 運用体系の構築
• ガイドラインの設定と遵守
• リスク管理
• システムの調達方法の策定

https://www.abitus.co.jp/column_voice/cisa/column_voice14.html

Webサービスのガバナンスのイメージ

ITガバナンスはコーポレートガバナンスから派生していて、その一部がWebサービスのガバナンスとして有効なものになります。イメージ的には以下の図のようになります。

Webサービスのガバナンスの例

このイメージ図だけだと内容がよく分からないので、開発の部分についてガバナンスの例を確認してみます。運用しているサービスで利用している開発の関心事とガバナンスの関心事を比較したものです。

開発の関心事

• PHP
• Java
• Javascript
• Yii2
• ドメイン駆動設計
• テスト
• レビュー
• 予算
• 期限

ガバナンスの関心事

• サービス提供に適切な開発言語か
• テストは適切に実施できているか
• レビューは適切に実施できているか
• 予算超過していないか
• 期限は守られているか
• 証跡は残しているか

この対比から、ガバナンスでは開発での具体的な項目は扱わず、サービスを運用するに当たっての開発のチェック項目になっているということが分かります。

ガバナンスのまとめ

• サービス運用のベストプラクティス
• 開発、運用、セキュリティ、コンプライアンスに関するチェックリスト

3.運用担当しているWebサービスでの障害の過去事例と改善のアプローチの紹介

ガバナンス強化による改善事例を3つ紹介します。一つ目の事例は、AWSのガバナンス機能を利用して、本番環境へのリリース時に承認を必要とすることで障害を未然に防ぐ対策の例です。二つ目の事例は、運用しているサービスが提供すべきガバナンス機能をAWSの機能で安価に実現する例です。三つ目の事例は、AWSの機能を利用して外部からの脅威に対策する例です。

事例1: 承認されていないリリースによりログインが出来ない

障害の概要

• 5分間程ログインが出来ない障害
• 開発中のブランチを誤って本番環境にリリースしたため
• 2022年9月に発生

改善対策: 承認されていないリリースの防止

AWS環境のシステム構成の概要は以下の図のようになっています。アプリケーションは本番環境アカウント内のEKSで稼働していて、管理アカウントから本番環境アカウントで稼働しているアプリケーションを更新する構成になっています。

リリース作業は運用担当者が対応しますが、アプリケーションの更新を反映する際に運用責任者の承認が必要になっていて、承認されていないリリースや運用担当者のオペミスによる本番環境へのリリースを未然に防げるようになっています。

リリース成功と失敗の例

リリース時は最初に運用担当者がリリース用のトークンを発行するコマンドを実行します。その後、運用責任者から承認をもらいトークンを発行して、そのトークンを利用してリリースコマンドを実行するとリリースが成功します。以下の図は、運用責任者による承認の場合はリリースが成功し、運用担当者が自身で承認をした場合は失敗している例になります。

利用しているAWSの機能の概要

AWS IAM

AWSアカウント内のユーザー、グループ、ロール、権限を管理するサービス。

AWS IAM Identity Center

複数のAWSアカウント内のユーザー、グループ、ロール、権限を一元管理するサービス。複数のAWSアカウントでのSSOやCLIを実行する際の権限付与機能を提供。

AWS Organizations

複数のAWSアカウントを一元管理するためのサービス。環境ごとにメンバーアカウントを用意して環境を分離。

AWS Control Tower

複数のAWSアカウント環境のセットアップを⾃動化するマネージドサービス。ベストプラクティスに基づく初期構成を提供。

AWS CloudTrail

AWSリソースへのアクセスや操作ログを取得するサービス。予期していないシステム構成の変更が発生した際に利用する。

事例2: リスト型攻撃を受けた時の調査コストが高い

現在運用しているサービスでは、サービスがリスト型攻撃を受けた際に被害範囲の特定とユーザーへのフォローアップが必要になっています。以下のフローで対応しています。

リスト型攻撃を受けた時の対応フロー

1. リスト型攻撃を受ける
2. 攻撃を検知して通知を受ける
3. グラフでログイン試行数が増えているか確認
4. ログイン試行数が増えていたらElasticsearchで詳細確認
5. リスト型攻撃が発生した時間帯にログイン成功しているユーザーを特定
6. パスワードリセットの案内メールを送信

ログイン試行数が増えているかをElasticsearchで確認する仕組みになっていて、このElasticsearchの運用にコストが掛かっているのが現在課題となっています。Elasticsearchで調査するメリットとデメリットは以下のようになっています。

Elasticsearchで調査するメリットとデメリット

• メリット
  • 攻撃を受けたユーザーを容易に特定に出来る
• デメリット
  • 運用コストが高い
    • 発生頻度は年に数回だがElasticsearchは常時稼働している
      • インスタンス3台以上
      • Tera単位のディスク
    • Elasticsearchのメンテナンス必要

改善対策: リスト型攻撃を受けた時の調査時だけ分析基盤を利用する

リスト型攻撃を受けた時の調査で利用する分析基盤は以下のように改善しています。

• ログイン履歴はAmazon S3に保存しておく
• 攻撃を受けた時の調査時にAmazon Athenaで攻撃を受けたユーザーを特定する
• コスト改善
  • 分析基盤(Elasticsearch)のコストが数万円/月から数千円/月に改善する見込み
  • 分析基盤管理コストは解消出来る

利用しているAWSの機能の概要

AWS Athena

Amazon S3にあるデータに対してSQLで分析出来るサービス。AWS Glueと連携して、ログイン履歴をクエリを実行し易い形に整形出来る。サーバーレスでインフラ管理不要。

事例3: 新たな脅威への対策 – 個人情報を狙うランサムウェアへの対策

新たな脅威への対策として、ランサムウェアへの対策を検討しました。運用しているサービスでは個人情報を取り扱っているため、個人情報をランサムウェアから保護する対策を検討しました。ランサムウェアの特徴をいくつか挙げてみます。

ランサムウェアとは

ランサムウェアとは、感染するとパソコン等に保存されているデータを暗号化して使用できない状態にした上で、そのデータを復号する対価（金銭や暗号資産）を要求する不正プログラムです。

https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html

最近のランサムウェアの傾向

• 要求された身代金を支払ってもシステムが復旧されないケースも発生している
• ランサムウェア対策部分も攻撃対象
  • DBのバックアップを暗号化する等
• しっかり対策をしていない状態で被害に遭うと甚大な被害へと発展

ランサムウェアの侵入経路

• アプリケーションの脆弱性を突いた攻撃
• 認証情報の漏洩による攻撃
• 設定ミスを狙った攻撃
• 内部者による攻撃
• サプライチェーン攻撃
• データベースを標的とした攻撃
• ログとモニタリングシステムの改ざん

https://www.cloudbuilders.jp/articles/4398/

ランサムウェア対策

ランサムウェアの特徴を踏まえて対策を検討してみました。

• 侵入経路を作らない
• 侵入の検知
• 被害を受けた場合の復旧

ランサムウェア対策 – 侵入経路を作らない

侵入経路には以下のような対策が有効です。

• アプリケーションの脆弱性を突いた攻撃
  • AWS WAF
• 認証情報の漏洩による攻撃
  • 2段階認証(MFA)
• 設定ミスを狙った攻撃
  • AWS Config
  • AWS Security Hub
• サプライチェーン攻撃
  • Amazon ECRイメージスキャナ

ランサムウェア対策 – 侵入の検知

以下の機能で侵入を検知出来ます。

• AWS Security Hub
  • AWS環境全体のセキュリティ状況を統合的に管理、監視するサービス
• AWS Detective
  • 潜在的なセキュリティ問題の根本原因を特定するサービス
• AWS GuardDuty
  • AWSアカウントとワークロードの脅威検出サービス
  • 「ランタイムモニタリング」（準リアルタイム）2023年 提供開始
  • EKSやECS、 EC2上のランタイムにおいて、OSレベル、ネットワーク、ファイルイベントなどを監視/分析し環境内で起こる脅威を検出

検知システムのコスト

次に検知システムのランニングコストです。料金体系が複雑で見積もりが難しいので、事前検証で上記の検知システムを導入して、30日間の無料期間で発生した金額をご紹介します。実際の運用が始まるとより多くのコストが発生する見込みなので、ミニマムの金額になります。

• AWS Security Hub: $7.81/月
• AWS GuardDuty: $2.55/月
• AWS Detective: $580/月
• 合計: $590/月

ランサムウェア対策 – 被害を受けた場合の復旧

もしランサムウェアの被害を受けても復旧出来るようにしておくのが望ましいです。復旧の対策としては以下のものがあります。

• DBのバックアップ取得
• バックアップの稼働環境のネットワークからの切り離し
• 定期的なバックアップからの復旧訓練

障害対応を改善するアプローチのまとめ

• 承認されていないリリースによりログインが出来ない
  • 対策: 承認されていないリリースの防止
• リスト型攻撃を受けた時の調査コストが高い
  • 対策: ログイン履歴の調査時だけ分析基盤を稼働させる
• 個人情報を狙うランサムウェア
  • 対策: 侵入経路を作らない、侵入の検知、バックアップからの復旧

4.どのようにガバナンス機能を導入するか

これまでご紹介した内容は、既にサービスを運用していて運用中のサービスを改善するという内容でした。この項目では、これからAWSでのサービス運用の開始を検討していて、ガバナンス機能を導入してサービス運用を強化したいと考えている方向けに参考となる形でまとめてみたいと思います。

初期段階で導入したい機能

ユーザーや権限の一元管理、ワークロード環境の分離等、サービスの運用開始から役立つ機能をベストプラクティスに基づいて提供する以下の機能は初期段階で導入しておくのが良いかと思います。

• AWS Control Tower
• AWS IAM Identity Center
• AWS Organizations
• AWS CloudTrail

検証と導入の順序の例

一方、これらの機能群はマルチアカウント環境での運用を想定した構成になっています。そのためAWS環境での運用経験がなく、例えばAWS IAMから学習を始めるといった段階の方には、最初から取り組むには難しい内容となっているように思います。これからAWS環境の運用を始める場合は、一例として以下のように単一のAWSアカウントでの運用を想定して、マルチアカウントでの運用のメリットと比較しながら導入を進めると良いかと思います。

1. 検証用に単一のAWSアカウントを作る
2. スイッチロールによるユーザーへの権限付与モデルを理解して設定する
3. 運用で利用する管理用のAWSアカウントを作る
4. AWS Control Towerを有効にする
   1. IAM Identity Center、Organizations、CloudTrailも有効になる
5. AWS IAM Identity Centerでユーザーとグループ、権限を管理する

このアプローチの注意点としては、単一アカウントでの検証と運用で使うアカウントは別のアカウントにするという点です。単一アカウントで検証した後にそのアカウントでAWS Control Towerを有効にすると、そのアカウントが管理アカウントになります。この時管理アカウントには、検証で利用したものが引き継がるため、不要なIAMユーザーやロール、ワークロード等が残存した状態になり、運用上好ましくない状況が発生するためです。

サービスで扱うデータやユーザー数の見通しを元に導入計画を立てる

初期段階で導入しておきたいガバナンス機能はありますが、無闇にガバナンス機能を導入するとサービス展開の遅れやランニングコストの増大に繋がるので、適切なタイミングでサービスに導入することが重要です。そのためにサービス運用の初期段階でガバナンス強化計画を立てておくと良いと思います。

一例としてサービス運用時に発生するリスク対策の計画を立てる場合についてご紹介します。サービス運用時に発生するリスクとしては以下のようなものが考えられます。

• サービス停止
• 個人情報漏洩
• システム改竄
• 信頼低下
• システム復旧コスト
• 売上損失

リスクを引き起こす要因と対策の表を作り、各リスク対策の効果の有無を入力すると全体的な費用対効果が分かります。

対策/脅威	ストレージ障害	DDoS攻撃	SQLインジェクション	ランサムウェア
リソース監視	◯	◯	×	◯
DBバックアップ	◯	×	◯	◯
監査ログ	×	×	×	◯
WAF	×	◯	◯	◯
最小権限の適用	×	×	◯	◯
脅威検知	×	×	×	◯

ガバナンス計画の例

リスク対策の費用対効果を検討して、サービス開発の初期段階でガバナンスの計画を立てます。サービス運用上効果の大きいリソース監視やDBバックアップはサービスのローンチ時に合わせて導入して、脅威検知は決済機能のような高いセキュリティが求められる時に導入するといった計画が立てられます。このような対応により、サービスの展開を早めつつ安定したサービス運用を実現することが出来ると思います。

5.まとめ

• ガバナンスはサービス運用のベストプラクティス
• PoC段階からガバナンスを意識して計画を立てる
• AWSの機能で効率的にガバナンスを実現
  • AWS Control Tower
  • AWS IAM Identity Center
  • AWS Organizations
  • AWS CloudTrail

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。