AWSやAzureのクラウドが危険になるのは「ユーザーの知識不足」のせい？：クラウドに潜む10大脆弱性【前編】
「Amazon Web Services」（AWS）などのクラウドサービスを利用する際、ベンダーは全てを守ってくれるわけではない。ユーザーが知っておくべき、クラウドサービスの脆弱性とは。
「Amazon Web Services」（AWS）や「Microsoft Azure」などのクラウドサービスでは、アプリケーションやデータが攻撃や窃盗などの不正行為から自動的に保護される――そう考えているなら、それは間違いだ。クラウドサービスベンダーもユーザーも、セキュリティの確保においてそれぞれ責任を負うことになる。
クラウドサービスでも、脆弱（ぜいじゃく）性、設定ミス、攻撃の可能性を完全には排除できない。本稿は、脆弱性という言葉を「セキュリティ体制における見落とし、ギャップ、弱点などの欠陥」という意味合いで用いる。クラウドサービスを利用する上で気を付けるべき脆弱性を10個紹介する。
1．構成ミス
併せて読みたいお薦め記事
未知の脅威やリスクに対処する
クラウドサービスでアプリケーションをホストする各種リソースとサービスを構成するのはユーザーの役割になる。ITチームは優先順位を付けて、多種多様な設定とオプションを学ぶ必要がある。
リソースやサービスのアクセス権限は基本的に制限する必要がある。仮にアクセス権限の設定に見落としがあると、外部からのアクセスを許し、悪用や変更が可能になる恐れがある。
構成のオプションやパラメーターはクラウドサービスベンダーごとに異なる。アプリケーションをホストするインフラの構成やクラウドサービスの仕組みを理解して実践するのはユーザーの役割になる。
構成ミスやその被害を軽減するため、ITチームは以下のような措置を講じることができる。
- 特定の業務やアプリケーションからアクセスする必要がないリソースやクラウドサービスへのアクセスをブロックする
- リソースやクラウドサービスに必要な設定を概説する明確な業務ポリシーとガイドラインを策定して使用する
- クラウドサービスベンダーが提供するポリシー設定ツールを利用する。デフォルトの設定はリソースを限定公開とする
- クラウドサービスの構成とセキュリティ設定を習得するため、ベンダーが提供する学習コースや認定資格の受講や取得を検討し、新しい設定やオプションには細心の注意を払う
- デフォルトで暗号化を使用し、保管中および移動中のデータを可能な限り保護する
- ソフトウェアベンダーIntruder Systemsの「Intruder」やソフトウェアベンダーOpen Ravenの「Open Raven」などの監視ツールを使って、構成ミスと監査ログを確認する
2．不十分なアクセス制御
攻撃者や一部のユーザーは、アクセス制御が十分になされていないIDとアクセスの管理に付け込んで、認証のメカニズムを回避する。
例えば、悪意を持ったユーザーは脆弱（ぜいじゃく）なパスワードを巧みに利用して資格情報を推測する。パスワードの最低文字数、大文字と小文字の併用、記号の使用、定期的なパスワードの変更など追加の要件を適用して、アクセス制御を強化する。
次のような一般的な手段を用いて、アクセス制御のセキュリティを強化する。
- 一定の桁数や記号を用いた強力なパスワードを強制する
- 多要素認証（MFA）を導入する
- 資格情報を記憶するのを避け、定期的に再認証を求める
- ユーザーが必要最低限の権限だけを与えられる「最小権限の原則」（PoLP）または何も信用しないことを前提とする「ゼロトラスト」の考え方を採用する
- サードパーティーのアクセス制御ツールを避ける
3．シャドーIT
クラウドサービスのアカウントは誰でも作成できる。セキュリティに詳しくないユーザーがデータ管理やセキュリティオプションの構成を誤り、クラウドインフラにあるデータやアプリケーションが悪用されかねない状態のまま放置していることが珍しくない。ITツールを会社の承認を得ずに使う「シャドーIT」については、悪用の報告がなされないこともあり、企業は取り返しがつかない状態になるまで問題緩和の機会を得られなくなっている。
企業内の組織や従業員は、自社が定める標準や法規制要件に従い、脆弱性の拡大防止と自社全体の安全確保に努める必要がある。
4．安全でないAPI
特に連携設定がされていないソフトウェア同士は、API（アプリケーションプログラミングインタフェース）を介して相互に通信する。ソフトウェアのAPIは一般的に、迅速な導入を支援する目的で公開されている。APIには機密性があるデータへのアクセスを許可する必要があるが、残念ながら十分な認証や承認を介さずに実装されているAPIがある。
認証や承認の機能がサポートされないAPIがある。APIが認証や承認の機能をサポートしているとしても、ユーザーが敬遠して使用していないのが実情だ。このようなAPIは、インターネット接続があれば誰でもデータにアクセスできるため、データが侵害される恐れがある。
安全ではないAPI、またはセキュリティが脆弱といった欠陥があるAPIが、近年のサイバー攻撃の標的として急浮上している。
クラウドサービスベンダーのAPIを使用するのであれ、クラウドサービスにデプロイするAPIを作成するのであれ、APIを使用および開発する際には以下の点に留意すべきだ。
- 強力な認証
- データ暗号化
- アクティビティーの監視とログ記録
- アクセス制御
APIを開発して実装する企業は、APIが社内の機密性の高いデータにアクセスできることを認識し、徹底的なセキュリティレビューの対象だと考える必要がある。外部のAPIについても同様に綿密な検査を実施することが不可欠だ。確立したセキュリティガイドラインを満たさないAPIの使用は避けるべきだ。
5．侵害
インフラのセキュリティについてはクラウドサービスベンダーが責任を担い、データやアプリケーションのセキュリティはユーザーが責任を担う。この共有責任モデルの考え方の下で、クラウドサービスベンダーだけではなくユーザーもセキュリティの責任を負う。
攻撃者がクラウドサービスの脆弱性を悪用して正当な業務目的なくデータにアクセスできた場合、データ侵害とそれに起因する結果についてはユーザーが全責任を負うことになる。結果として考えられる例は次の通りだ。
- 顧客の機密データが盗まれた場合、企業は法規制の順守義務を怠ったとして評判を失う
- 重要なデータが盗まれた場合、知的財産を失い、自社の競争力が低下し、当該データを生み出すために実施した投資が無駄になる
- 社内の業務データが変更または削除された場合、生産上の問題などさまざまな影響が生じる
侵害が起きれば企業はその報いを受ける。例えば、法規制の要件に違反する侵害が起きれば、罰金や刑罰を受ける可能性がある。顧客のために保管していたデータが侵害されれば、訴訟や改善措置が必要となる。
次回はクラウドサービスを利用する上での6〜10個目のポイントを紹介する。
TechTarget発 先取りITトレンド
米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。
Copyright © ITmedia, Inc. All Rights Reserved.