サイバー攻撃に対し、AWS上でのセキュリティ対策をどのようにして講じるのか

2009年にTISがAWSのサービスを開始して以来、この10年間でAWSの利活用は爆発的に増え、この2～3年では、銀行など金融分野での採用も増加しています。これにともない、クラウド環境でのセキュリティ関連の事故も増えつつあります。

2018年には、コインチェック社で、マルウェアの感染によって580億円の仮想通貨が流出する事故が起きました。この事故は、セキュリティの考慮不足に加えて、水際のセキュリティ対策の不足が原因だったと考えられます。また、2017年に起きた、米Equifaxの1億件以上の情報漏洩事故は、Apache Strutsの脆弱性をつかれたものですが、脆弱性の発見から情報流出、パッチを当てるまで半年くらい時間が経過していたといわれています。

米ウーバー・テクノロジーズでは、2017年に利用していたクラウドサービス側に存在していた脆弱性をつかれて個人情報が流出するという事故が発生しました。問題は、利用者側が権利やアクセス権に気をつけていたとしても、サービス側に不手際があった場合には、事故を防ぎきれないというところにあります。しかし、問題をきちんと発見・把握して、エスカレーションを行い対応する“インシデント・レスポンス”の視点がもれていたのではないかとも考えられています。

これらの事例は、すべてクラウド環境で発生しているのですが、過去にはオンプレ環境でも同じような事例は起きています。つまり「クラウドサービスがすべてを保証してはくれない」という前提に立って、適切なセキュリティ対策を講じることが利用者側に求められているのです。そう考えたときに、どこに課題があるのでしょうか。

クラウドは利用しているサービスや機器を含めて“情報資産”です。ISO27001に代表されるセキュリティ標準の中にも、サービスに関して情報資産として扱い、きちんとリスクを評価すべき、ということが定義されています。

クラウドを情報資産と捉えて、クラウドサービスそのもののセキュリティの状況を評価しないと、クラウドサービスの脆弱性や保証していない部分での問題から、データが流出したりサービスが停止するということが起こりえます。

セキュリティ製品に完璧なものはありません。製品の弱点を踏まえて、いかに検知できる仕組みを構築するかが重要です。
そのためにサービスや機器を含めた情報資産をしっかりとグルーピングし、それぞれを評価する必要があります。

細かすぎず、粗すぎない適切な分類をすることで、偏った投資をすることなく、全体から見て工数と対策費用のバランスが取れたセキュリティ対策が実現できます。

セキュリティでは、データ漏洩など機密性だけが重要視される傾向があります。しかし、情報資産が企業の活動に必要な仕組みであることを考えると、事故が発生したときの影響度を考慮した完全性、復旧に許される時間といった可用性の観点も持つことが重要です。

クラウドサービスを情報資産として捉え、機密性、完全性、可用性の3つの観点を踏まえたインシデント対応フローを整備しておかないと、セキュリティ被害の拡大を防ぐことができません。

これらの3つの課題を解消するために、TISでは以下の3つのステップを踏まえた「セキュリティ・バイ・デザイン」のセキュリティ対策を講じることをお勧めしています。

ステップ1：情報資産の区分、価値を明確にする

最初のステップとして、情報資産であるクラウドサービスがどれくらいの価値を持っているのか、利用者の用途に応じてどういったリスクがあるのかを判定し、整理していきます。

まず定性的な観点から評価基準を設定し、ケースごとにリスク評価結果をスコアリングしていきます。それぞれについて可用性、完全性、機密性で評価し、その合計値で最重要、重要、一般といった基準に当てはめていきます。

ステップ2：リスクベースでサービスと機能を決定する

次にステップ1のリスクのスコア値をベースに、実装すべき機能を選定していきます。例えば、一日程度の復旧時間が許容できるレベルの情報資産であれば、通常のバックアップからリストアで対応できるので、DDoS対策は不要だと判断することが可能です。

こうしたリスクと対応方針などを一覧できるテンプレートを作っておくことで、重要度に応じて機能をマッピングしてセキュリティ対策を標準化することができ、今後AWS環境に移行/構築していくシステム間においてもセキュリティ対策の不整合を抑止することも可能になります。

ステップ3：被害を最小限に抑える運用強度を設定する

最後に情報資産価値に応じて運用強度を選定します。あらかじめ算出したリスクのスコア値に応じて強度を決定し、事故が発生した場合にどういうインシデント対応を行うべきかを検討し定義しておきます。

例えば、機密性が最重要の情報資産には、セキュリティ侵害に気づくまでの対応速度の目標を設定し、SOCによる常時監視など時間を短縮するための仕組みを実装し、事故発生時の対応フローも定義しています。

クラウドサービスを情報資産と捉え、対応要件の抽出と評価を行い、評価の結果を機能選定マップに落とし込み、運用強度に応じた実装をしていくという「セキュリティ・バイ・デザイン」では、PDCAサイクルを回して、常に対策の妥当性を評価し、セキュリティのレベルを維持することが重要です。

TISでは、これまでの10年間にわたるAWSの経験を踏まえ、クラウドサービス活用のコンサルティングから、リスク評価や機能マッピングなどのテンプレートの提供、実際のクラウドの運用業務支援までをワンストップで提供しています。それにより、「セキュリティ・バイ・デザイン」のPDCAサイクルをフォローし、AWSの安全な活用をトータルでサポートしています。