予算が多くない中小企業にとって、高度なセキュリティ対策は困難だと思われがちだ。しかし、そんな企業こそクラウド活用によって享受できるメリットは大きい。本稿では、AWSが提供するサービスによっていかに高いレジリエンスを実現できるのかについて解説する。
この記事は会員限定です。会員登録すると全てご覧いただけます。
本連載は「オンプレミス環境でセキュリティ面に課題を持っている」「セキュリティ面の不安からクラウド移行に踏み切れない」「クラウドに移行したいが経営層を説得できない」といった悩みを持つ中堅・中小企業に向けて、クラウド移行がもたらすセキュリティメリットを解説している。
連載第4回では、米国国立標準技術研究所(以下、NIST)の「サイバーセキュリティフレームワーク」(以下、NIST CSF)に基づいた「検知」機能の紹介と、パブリッククラウドのデファクトスタンダードである「Amazon Web Services」(以下、AWS)へ移行することで「検知」機能のセキュリティ対策がどのように変わるのかについて解説した。
最終回となる本稿は、NIST CSFの「対応」と「復旧」に分類されるセキュリティ対策に基づいて、AWS移行で得られるセキュリティメリットを解説する。
本連載は、クラウドのセキュリティに不安を感じている中堅・中小企業に向けて、全5回にわたってクラウドのセキュリティメリットや注意点を紹介する。クラウド移行を考える際に参考にしてほしい。
NIST CSFにおける「対応」と「復旧」機能には、検知したインシデントを迅速に対処し、元の状態へ復旧させる為の対策がまとめられている。図1はNIST CSFの機能分類と各サブカテゴリーだ。
「対応」と「復旧」はセットで検討されることが多いことから、サブカテゴリーも共通しがちだ。実際にサブカテゴリーの一つ目はどちらも非常時に備えた「計画」の作成だ。例えば、本番環境での障害発生に備えて、発生する可能性があるアラートの一覧や、各アラートに対する対応手順書を作成したことはないだろうか。これが「対応計画」と「復旧計画」の作成だ。
サブカテゴリーの「コミュニケーション」は、インシデント対応時に関係者と円滑に連絡を取る手段を用意することを指す。インシデント発生時には、上長やベンダー、場合によっては司法当局や攻撃側システムの所有者など、さまざまな関係者とのコミュニケーションが必要になるため、最低限、社内の最終エスカレーション先としてこれらの対応が可能な人間を設定しておくことが推奨される。
サブカテゴリーの「改善」は、実際の対応から得られた教訓を計画に反映することだ。どれだけ入念に計画を立てても、サービス稼働前に抜け漏れのない計画を作成することは難しい。対応・復旧作業の度にフィードバックを行い、計画を改善することが重要だ。
筆者は、レジリエンスを高める為に大切なことは「システムの理解」「計画の改善」「メンバー教育」だと考えている。あらかじめ「どんなインシデントが起こりうるか」「どう対処すればよいか」をまとめておくことで、インシデント発生時の初動を高速化できる。
しかし、大規模なシステムはアップデートを通して変化し続けるため、全てを網羅した対応・復旧計画を策定することは不可能だ。そこで、計画の改善が必要不可欠であり、また、どのメンバーが障害対応を行うか予測できないため、“関係者全員の習熟度”を上げることが重要だ。
これらの点を踏まえた高度な「対応」「復旧」機能の例としては、Netflixが行っている「カオスエンジニアリング」が有名だ。カオスエンジニアリングは、本番システムにわざと「カオス=異常」を発生させ、その挙動から対応・復旧計画を検証する訓練方法だ。カオスエンジニアリングは大まかに以下の手順で行われる。
1 システムが正常稼働している状態を「定常状態」として定義する
2 カオスが発生した際に「定常状態」を維持できるか検討し、仮説を構築する
3 カオスを注入し、実験する
4 検証・改善を行う
カオスエンジニアリングの優れている点は、システム理解と計画改善、メンバーの訓練を同時に行える点にある。実験を通してシステムの挙動を理解し、計画をアップデートできるこの手法は効率が良い。また、カオスエンジニアリングは実際に本番システムの障害対応を実施することにもなるので、メンバーの習熟度も上げられる。このような「対応」・「復旧」機能を用意することで、システムを安定して運用できる“自信”を得られるだろう。
AWSのシステムでは物理的な対応計画が不要なため、AWS移行は「対応」「復旧」機能においても効果的だ。連載第1回でも触れたが、AWSを利用する際にハードウェアの保守はAWSの責任範囲になる(責任共有モデル)。
つまり、AWS上のシステムはHD故障に対する交換対応やサーバ故障時の修理対応、NW機器故障に対する副系切り替え対応など、物理障害の対応計画をユーザー側で用意する必要がない。障害対応自体もほとんど「AWS マネジメントコンソール」を中心に実施するため、オペレーターの負担を軽減できる。対応計画をシンプルに統一し、余ったリソースをメンバーのトレーニングに回すことで、システムのレジリエンスを高められる。
AWSにはカオスエンジニアリングのためのサービス「AWS Fault Injection Service」(以下、AWS FIS)がある。図2はAWS FISで用意されている実験シナリオの一覧だ。
「AZの可用性: 電源の中断」というシナリオを利用すれば、アベイラビリティゾーン障害が発生した際にシステムがどんな挙動を取るのかを観測できる。他にも任意のアクションを組み合わせて実験テンプレートを作ることもでき、システム構成に合わせて柔軟にシナリオを作成できる。
また、AWS FISはモニタリングツールと連携して本番に影響が出そうになった場合に実験を強制停止する事も可能だ。通常、カオスエンジニアリングを行うためにはエージェントの導入やアプリの改修など、準備が必要だ。この点、AWS FISは他のAWSサービスと直接連携して動作するため、システムに変更を加えずに利用できる。手軽に本番と同じ障害をシミュレートし、質の高い訓練を実施できるのはクラウドならではだ。
Amazon Web Servicesは同社の年次イベント「AWS re:Invent 2023」にて、AI(生成AI)アシスタントサービス「Amazon Q」を発表した。Amazon Qは生成系AIチャットbotで行える一般的なタスクに加え、社内ドキュメントの検索も簡単に実装できると話題を呼んだ(2023年12月初旬ではパブリックプレビュー中で、英語のみ対応。正式リリース時には仕様が変わる可能性あり)。
同サービスは、顧客のさまざまなビジネスシーンをサポートするAIアシスタントサービスとされているが、「対応」「復旧」機能も強力にサポートする。Amazon QはAWS公式ドキュメントを学習しており、一般的なAWSサービスの仕様から利用方法、トラブルシュートの対応方法まで、多様な質問に回答する。以下は「AWS Lambda」をテスト実行し、エラーを発生させた際のスクリーンショットだ。
「Analysis」には、何が原因でこのエラーが発生したかが記述されている。「Resolution」には解決方法のヒントが提示され、ユーザーは迅速にコード修正に取り組める(2023年12月現在、米国オレゴンリージョンでのみ利用可能)。第4回の「検知」機能で紹介した「Amazon Detective」には、図5の赤枠部分の様にAIインサイトが追加された。
これによって、ユーザーは現状を把握しやすくなり、対応や復旧速度を向上させられる。インシデント対応の現場では想定外の事象がたびたび発生し、自力でのトラブルシュートを迫られる場面が多い。そんな中で気軽に質問し、信頼できる情報ソースからの回答をすぐに得られるのは「対応」「復旧」機能において大きなメリットだ。
本連載は5回に渡ってセキュリティ対策としてのAWS移行の有効性について解説した。
セキュリティ対策としてのAWS移行のメリットは、物理的セキュリティの責任範囲をAWS側に切り出し、論理的セキュリティ対策に注力できるようになる点だ。限りあるリソースを有効活用しなければならない中小企業こそ、AWS移行のメリットを享受できる。
AWSは本連載で紹介したサービス以外にも、セキュリティ対策に有効なさまざまなサービスを用意している。ユーザーはセキュリティ対策をゼロから学ぶのではなく、AWSサービスの使い方を理解すればよいという意味で、学習コストを下げられるだろう。システム移行を検討する際は、AWS移行を選択肢に入れてもらえると幸いだ。
Copyright © ITmedia, Inc. All Rights Reserved.