クラウド環境
クラウドやコンテナの設定ミスから重大な脆弱性が発生
2027年までに、グローバル企業の90%以上がコンテナアプリケーションを運用するものと予測されています。2023年の時点でも、企業の63%がクラウド・ネイティブの戦略をビジネスの中に取り入れています。
2027年までに、グローバル企業の90%以上がコンテナアプリケーションを運用するものと予測されています。2023年の時点でも、企業の63%がクラウド・ネイティブの戦略をビジネスの中に取り入れています。こうした動きが始まった当初、クラウドへの移行は単なるインフラの変更に過ぎず、従来のセキュリティ原則が概ね維持されるものと想定されていました。
当時、システム管理者や開発者、運用チームが対峙すべき脅威と言えば、それは主にマルウェアや、脆弱性の不正利用を指していました。サイバーセキュリティチームの主な業務は、標的型攻撃に利用されるマルウェアを解析し、ペネトレーションテストを通して脆弱性を精査することであり、そのアプローチを大幅に変える必要はありませんでした。
しかし現在、こうした想定は全く成り立たなくなっています。企業がクラウドに移行してコンテナ技術を取り入れた結果、さまざまな選択肢や変動要素が追加で発生し、運用面での要望とセキュリティ面での要望のバランスを取り難くなっています。例えば、ネットワーク設定などの技術的要素と、コンプライアンスや市場投入タイミングなどの戦略的要素を併せて調整することが、困難になっています。こうした複雑さに絡む問題は、企業や組織における「設定ミス」のリスクを増大させます。設定ミスの脅威は目に映りにくいですが、重大な脆弱性に繋がるものであり、今後、クラウド業界を急速に侵攻していくと考えられます。
変化するクラウドセキュリティのパラダイム
クラウドサービス・プロバイダ（CSP）は、セキュリティ上の責任をプロバイダ自身とユーザの間で明確に切り分ける「責任共有モデル」を採用しています。基本的にCSPは、「クラウド自体」のセキュリティを受け持ちます。例えば、クラウドサービスとして提供されるインフラやハードウェア、ソフトウェアなどが該当します。一方、クラウドサービスのユーザは、「クラウド内部」のセキュリティを受け持ちます。例えば、データやアプリケーション、ユーザ・アクセスなどが該当します。
CSPは、サーバやストレージ、ネットワーク・コンポーネントなどの物理的なインフラをセキュアな状態に保つ必要があります。これには、ファイアウォールや物理アクセス制御、定期的なセキュリティ監査なども含まれます。サービスや責任共有モデルの種類によっては、オペレーティングシステム（OS）のパッチ適用もCSP側で担います。
ユーザ側は、特にクラウド内に配備された自身のデータについて、責任を負います。これには、暗号化やデータ損失防止、アクセス制御の機能呼び出しも含まれます。例えば、データを保管、転送する際の暗号化機能がCSP側から提供される場合でも、実際にデータをアップロードする際に当該の暗号化機能を呼び出すことや、暗号鍵を適切な方法で管理することについては、ユーザ側の責任となります。
- サービスとしてのインフラ（IaaS）：CSPは、仮想マシンやストレージ、ネットワークなどの基本的なインフラを提供する。これに対してユーザは、OSやアプリケーション、データに関する責任を負う。
- サービスとしてのプラットフォーム（PaaS）：CSPは、インフラや、アプリケーションを動かすプラットフォームの管理を担う。ユーザは、アプリケーションのロジックやデータを取り扱う。例としてCSPは、OSレベルまで管理の行き届いたサーバや、クラウド・コンテナサービスに必要なネットワーク、ストレージを提供する。これに対してユーザは、アプリケーションのコードやデータのセキュリティに関する責任を負う。
- サービスとしてのソフトウェア（SaaS）：CSPは、インフラからアプリケーションに至るほぼ全体を管理する。ユーザは、サーバレス・サービスなどを使用する際のデータやユーザアクセスについて責任を負う。
クラウドサービスの導入に伴い、アタックサーフェス（攻撃対象領域）も変化しています。特定の物理機器を狙った攻撃は、極めて稀なものとなりました。ユーザがクラウドサービスの利用を開始した時点で、CSPは、ローカルの物理機器に潜む脆弱性を狙った物理アクセスを全て阻止し、必要に応じて緩和策を講じる必要があります。一方、SaaSモデルを採用した場合、アプリケーション自体の管理やセキュリティ確保についてもCSP側で担います。これには、OSレベルのあらゆる脆弱性への対処や、修正パッチの適用も含まれます。
修正パッチを含めて全てのセキュリティ対策を的確に実施すれば、攻撃者の手がその分だけ封じられます。CSPがセキュリティ上の責任をより大きく受け持ち、対応するのであれば、全体的なアタックサーフェスも狭まります。こうした取り組みを進めることで、CSP側ではより安全なプラットフォームを提供し、ユーザ側では設定ミスのリスクを減らすことが可能です。
もう1つの重要な視点として、サービスの不用意な公開（または露出）が挙げられます。大半のCSPは、サービスのデフォルト設定に「最小権限の原則」を適用しています。ユーザが本原則から離れたい場合は、自身の判断で明示的にその変更を行う必要があります。このように、高リスクな設定に一定の敷居を設けることで、脆弱なアプリケーションが意図せずインターネット上に公開される事態を、ある程度まで防ぐことが可能です。
しかし、これは脆弱性の露出を完全に防止するものではありません。特に、IaaSモデルではユーザ側の責任範囲が広いため、そのことが強く言えます。例えば、ユーザが非常に緩いセキュリティ設定を利用し、古い脆弱性にも未対応のアプリケーションやOSをインターネットに公開するような事態も、十分に考えられます。仮にアプリケーションの設計や開発がIaaS環境の内部で行われるのであれば、CSP側でセキュリティ・ベストプラクティスを運用することで、脆弱性のリスクを削減できます。結果、不正利用や感染の標的となるファイルやライブラリが減り、環境の持続期間が短縮され、従来型の脆弱性がある程度まで抑制されると考えられます。しかし、依然として解消されない問題点が存在します。
近年におけるクラウド・セキュリティ事象の多くは、「設定ミス」という共通の問題を抱えています。
ユーザがCSPのセキュリティポリシーに遭遇し、その制約が個別の要望やユーザビリティにそぐわないように見えた時、確立済みのベストプラクティスから離脱しようとする傾向が見られます。このように、クラウドセキュリティの知識が不十分な状態でクラウドに移行すると、セキュリティポリシーを自ら緩めてしまう場合があります。
例として、コマンド「chmod 777」を取り上げます。本コマンドは、対象ファイルやディレクトリの読み込み、書き込み、実行の全アクセス権（パーミッション）を、全ユーザに付与します。こうした過大なアクセス権を開放する際にはセキュリティ面での十分な検討が行われるべきですが、経験豊富なシステム管理者でさえも、Webサイトを手早く起動したいというだけの理由で本コマンドを用いることがあります。
これと同じようなことは、今日のクラウドサービスでも見られるでしょう。問題の解決策として完全なアクセス権を付与することは、すでに実利重視の手段として習慣化しています。その背景には、開発現場のさまざまな要望があります。例えば、開発タスクの迅速化（アジャイル）、テストやトラブルシューティング時の例外的対応、パイプラインの自動化などが挙げられます。また、分散型のチームでは、業務効率のために広域的なアクセス権が望まれる傾向にあります。さらに、複数の内部ソースや外部ソースから来るデータをクラウド・プラットフォームに統合したい際にも、アクセス権の制約が問題になり勝ちです。
こうした習慣も相まって、企業や組織では、運用効率とセキュリティの境界線を見極める重要性について、認識できていないケースが見受けられます。理由として、ガバナンスやセキュリティ意識の欠如、早すぎる技術革新などが挙げられます。高いアクセス権をチェックボックス1つで許可している場合にしても、ID・アクセス管理（IAM：Identity Access Management）が緩すぎる場合にしても、その根底には、「動けばよい」という発想が垣間見られます。こうした発想は、セキュリティ体制の弱体化を招き、脆弱性を露出させる可能性があります。
クラウド/コンテナ利用時における設定ミスの例
- Amazon Web Service（AWS）のS3バケット：データを手早く共有したいという目的からS3バケットポリシーの設定を編集し、パブリックレベルの読み込みや書き込みを許可するケースが存在する。この場合、インターネット上の全ユーザにデータが公開され、情報漏洩に至る可能性がある。
- IAMロール：アクセス権に関する問題の解決策として、クラウドプロジェクト内の全ユーザに「オーナー」や「管理者」のロール（役割）を付与するケースが見られる。プロジェクト内でのあらゆる操作権限を全ユーザに開放すれば、必然的に、誤操作や不正行為のリスクが増大する。
GitHub上のオープンプロジェクトを調べると、権限設定の緩いデプロイファイルやインストールファイルが、数多く見受けられます。Stack Overflowにも、問題の解決策として、過大なアクセス権を許容する設定ファイルが頻繁に提示されています。
このように寛容すぎる設定ファイルがベンダーのドキュメントやコードスニペットとして提供されている場合、状況はさらに悪化します。ネットワーク設定ファイルを例に取ると、プロセスやAPI、フレックス型デーモンを開始するためのデフォルト値として、「0.0.0.0」が頻繁に指定されています。この場合、環境構成やファイアウォールのルール次第で、対象サービスがインターネット上の全ユーザ向けに公開されることになります。
設定ミス：クラウドやコンテナ環境の新たな脆弱性
近年におけるクラウド環境やコンテナ環境の複雑化は、設定ミスの大幅な増加を招いています。例えば、多くの企業や組織が、「マルチクラウド」の戦略を採用しています。産業研究グループ「ESG（Enterprise Strategy Group）」は、2023年に実施された「CDRS（Cloud Detection and Response Survey）」の調査結果として、企業や組織の69%が最低でも3つのCSPを利用し、83%が本番稼動のアプリケーションをクラウドに移行済みである旨を報告しました。企業や組織がクラウドへの移行を急ピッチで進める一方、個々のCSPは、それぞれ独自のやり方でセキュリティ管理を行い、独自の設定を採用しています。そのため、セキュリティチームにとっては、利用する全てのプラットフォームで一貫したセキュリティ体制をいかに維持するかが、重要な課題となっています。また、より多くの企業が複数のCSPを利用するに従い、スケーラビリティやプロセス自動化に優れたクラウド型検知・応答ソリューション（CDR）の重要性が、これまで以上に高まっていくと考えられます。
セキュリティを考慮せずにDevOpsや高速デプロイを導入する動き
DevOpsの実践としてデプロイ・サイクルを否が応でも早めようとする動きは、設定ミスのリスクに繋がります。ESGの報告によると、多くの企業や組織がDevOpsの開発手法を広範囲に適用していますが、そのために、十分なセキュリティ検査を通さずにソフトウェアをリリースしてしまうケースが頻発しています。結果、セキュリティを無視して機能のみに偏った設定が出来上がり、そこが脆弱なポイントとなって、攻撃者に狙われることになります。
また、ESGの調査に基づくと、DevOpsを用いる企業や組織の85%が、新たなビルド成果物を少なくとも週に1度以上の頻度で本番環境にデプロイしています。こうした窮屈なデプロイスケジュールは、やはり、設定ミスのリスクを増大させるものです。ビジネス上の要求に押されてソフトウェアの更新頻度を過度に高めても、セキュリティチーム側の手が回らなくなり、結果として設定の安全性を検査できなくなってしまうことが、多々あります。
クラウドやコンテナにおける設定ミスの代表例を、下記に示します。
- 認証不要のAPI：インターフェースに認証を設けない場合、不特定多数のユーザにアクセスされ、操作される可能性がある。
- ストレージバケットの公開：クラウドストレージ・バケットへのパブリックアクセスを許可すると、機密情報が流出する恐れがある。
- 本番環境でデフォルトパスワードを使用：広く知られている、または暴かれやすいデフォルトパスワードを本番環境で利用すると、攻撃者によって容易に不正アクセスされる恐れがある。
- 暗号化なしでデータを転送：データを暗号化せずにネットワーク経由で送信すると、中継点で内容を盗み取られる可能性がある。
- 過大なアクセス権：ユーザやサービスに対して必要以上のアクセス権を付与すると、誤使用のリスクが高まる。
- 不要なポートの開放：不要なポートを開いたままにしておくと、そこが攻撃者に利用され、システム内に侵入される恐れがある。
- セキュリティグループの設定不備：セキュリティグループのルール設定が緩すぎると、望ましくないトラフィックを受け付けてしまう可能性がある。
- 管理用コンソールの公開：適切なアクセス制御を設定せずに管理用コンソールをインターネット上に公開すると、不正アクセスの標的として狙われる恐れがある。
- 古いソフトウェアや依存関係：脆弱性を持つ古いバージョンのソフトウェアを稼動させると、そこが攻撃者に突かれ、データ侵害や機能障害に陥る可能性がある。
- ネットワーク分割の欠如：ネットワークを的確にセグメント化（分割）していない場合、攻撃者によって容易に水平移動・内部活動を実行され、被害範囲の拡大を招く。
設定ミスの不正利用によって発生しうる被害の具体例を、下記に示します。
- 情報漏えい：不正アクセスによって機密情報や認証情報を窃取され、外部に公開、または不正な目的で利用される。
- アカウント乗っ取り：アカウントを乗っ取られ、不正な活動に利用される。
- クリプトジャック：暗号資産マイニングのために計算リソースが不正利用される。リソースが食いつぶされる結果、パフォーマンスに悪影響が出る。
- サービス拒否（DoS：Denial of Service）：サービスへの大量アクセスによって機能不全に陥り、正規ユーザからのリクエストに対応できなくなる。
- データ損失：機密情報を削除、または改変され、復旧できなくなる。
- コンプライアンス違反：データを保護できなかった場合は規制要件に違反したものと見なされ、罰金や法的措置を科せられる可能性がある。
- 権限昇格：高いアクセス権を掌握され、より重要なシステムやデータに踏み込まれる。
- サービス障害：サービスの侵害により、業務運用や生産性に支障が出る。
- 知的財産の窃取：機密情報への不正アクセスによって企業秘密が流出し、競争力を損ねる。
- 金銭的損失：障害からの復旧作業や潜在的なブランド毀損により、直接的または間接的な金銭的損失が発生する。
「設定ミス」と「従来型の脆弱性」を比較
設定ミスと従来型の脆弱性を比べると、前者の方が発生条件が成立しやすく、より蔓延する傾向にあります。影響について考えると、設定ミスは、わずか1箇所の不備でもアプリケーションやデータ全体をインターネット上に晒す可能性があります。これに対して従来型の脆弱性は、多くの場合、技巧を凝らさない限り効果を及ぼしません。ESGの報告によると、2023年に企業や組織の大半がクラウドセキュリティのインシデントに遭遇し、その多くが設定ミスを伴うものでした。また、Telusによる2023年の報告「State of Cloud Security」でも、組織の74%が設定ミスによる重大なセキュリティインシデントに遭遇したと、述べられています。
攻撃者側の見方として、従来型の脆弱性を不正利用するにあたっては相応の技術経験が必要な場合が多く、設定ミスよりも敷居が高いと考えられます。例えばAmazon S3バケットが設定ミスによって公開されている場合、URLさえ分かれば、誰でもそこにアクセスできるでしょう。一方、よく知られているバッファ・オーバーフローの脆弱性があったとしても、そこを攻撃するためには、ソフトウェアや環境に関する詳細な知識が必要となります。
Telusの報告によると、クラウドセキュリティ・インシデントの約50%は、本来ならば回避可能な設定ミスに起因します。具体例として、デフォルト設定をそのまま使用するパターンや、ユーザやサービスに過大なアクセス権を付与するパターンなどが挙げられます。こうした設定ミスの背景には多くの場合、設定事項がセキュリティに及ぼす影響の見過ごしや、その理解不足があります。さらに同報告は、企業や組織の95%がこうした設定ミスに定期的に遭遇している旨を述べています。
以上に加えて同報告は、ゼロデイ攻撃がクラウドインシデントの原因として最下位に来るにも関わらず、最も注目を浴びる傾向にあることを述べています。これに比べて設定ミスは、より日常的な存在でありながら、より大きな脅威をクラウド環境やコンテナ環境にもたらしています。
設定ミスも従来型の脆弱性も、深刻な被害に繋がる可能性があります。しかし、設定ミスの方が、幅広い影響を及ぼす傾向にあります。実際に、クラウドストレージ・サービスの設定ミスが膨大な情報流出を引き起こし、数百万ものユーザに影響を与えかねないことが、多くの事例から示されています。これに対して従来型の脆弱性は、システムの深いところまで侵入を許す可能性がりますが、攻撃者にとっての敷居も高く、高度な技術や手順が必要となります。
設定ミスによる影響とその実例
設定ミスが重大なセキュリティ事故に繋がった事例として、2019年のインシデント「Capital One」がよく知られています。このインシデントでは、Webアプリケーション・ファイアウォールの設定ミスが原因となり、Amazon S3に保管されていた1億もの顧客履歴が不正にアクセスされました。本インシデントは、機密性の高い個人情報が流出したというだけでなく、クラウド環境の設定管理がいかに重要であるかを示す一例となりました。
別の事例では、TeslaのKubernetesコンソールをパスワード不要のまま公開していたため、Telsaのクラウド・リソースが暗号資産マイニングに不正利用できる状態となっていました。本インシデントは、コンテナ環境における管理インターフェースの保護や、的確なアクセス制御の重要性を示す一例となりました。
以前トレンドマイクロは、Docker APIの設定ミスが原因となってボットネットや暗号資産マイニング用マルウェアが配布される事例を報告しました。本インシデントでは、設定ミスを突いた攻撃者によってDockerコンテナへのアクセス権を掌握され、内部リソースが不正な活動に利用されました。
設定ミスは、すでに数年に渡り、クラウドにおける脅威の筆頭として挙げられています。2020年にトレンドマイクロが行った調査では、クラウドセキュリティに対する最大の脅威として、設定ミスが挙がりました。2022年のCloud Security Alliance（CSA）による報告でも、増加傾向にある設定ミスこそがクラウドセキュリティ・インシデントの要因であると、述べられています。2023年のTelusによる報告でも、クラウド環境に対する最も重大なリスクとして、設定ミスが挙がっています。
設定ミスはまた、金銭的損失を引き起こす可能性もあります。直接的な損失として、コンプライアンス違反による罰金の他、インシデント対応や修復に要するコストが挙げられます。間接的な損失として、顧客からの信頼失墜、ブランド毀損、ビジネスチャンスの喪失などが挙げられます。
Telusの報告によると、設定ミスを伴うクラウドセキュリティ・インシデントの平均損失額は、およそ386万米ドルにのぼると推定されます。また、IMBの報告によると、2023年に米国で発生したデータ侵害1件あたりの平均損失額は、収益の損失や監査費用、修復費用を含めて944万米ドルとなります。2018年から2019年にかけて、クラウドの設定ミスに起因するデータ侵害により、企業や組織は合計で約5兆米ドルの損害を被りました。
設定ミスは、法的な規制とも密接に関わっています。実際に規制当局は、クラウドセキュリティの運用法に対する監視の目を強めています。また、GDPR（EU一般データ保護規則）やCCPA（カリフォルニア州消費者プライバシー法）、HIPAA（医療保険の携行性 と責任に関する法律）などの各種規制により、データ保護やプライバシー保護に関する厳格な要件が定められています。こうした規制に違反すれば、多額の罰金を科せられる可能性があります。
先述した「Capital One」のインシデントでは、当該企業が8千万米ドルの罰金に加え、1億9千万米ドルの和解金を支払う旨で合意するに至りました。ESGの調査においては、企業や組織の約31%が、クラウドセキュリティ・インシデントによるコンプライアンス違反を報告しました。別の調査では、セキュリティやDevOps専門家の約50%が、クラウド環境の設定ミスやコンプライアンス違反、APIのセキュリティ不備のために、稼働停止時間が増加している旨を報告しました。
設定ミスの解決策とセキュリティ・ベストプラクティス
自動化と継続的な監視
手作業での設定には、ヒューマンエラーがつきものです。一方、自動化の仕組みを用いることで、一貫性のある設定やセキュリティポリシーを全ての環境に適用することが可能となります。その一例が、セキュリティ設定をプログラム的に行う取り組みであり、開発からテスト、本番適用に至る各工程のセキュリティ標準化に寄与します。また、手作業の設定編集によってIT環境の状態が本来の姿から離れていってしまった際に、これをセキュリティポリシーに合わせて自動修正するツールも存在します。さらに、セキュリティテストを自動化する取り組みも存在し、開発の初期段階で設定ミスを発見できる可能性が高まります。
自動化や継続的監視は、設定管理やリスク軽減を迅速かつ一貫した方式で行うためのアプローチであり、スケーラビリティにも優れています。企業や組織が投資先としてクラウド向けセキュリティソリューションやデータプライバシーを筆頭に挙げていることは、驚くべきことではありません。Gartnerの報告によると、2024年にはその割合が24%以上増加し、クラウドやAI技術も組み込まれていくと予想されます。
セキュリティトレーニングと意識向上
クラウドやコンテナ環境の安全性を確保する上では、セキュリティトレーニングや意識向上の取り組みが特に重要です。企業や組織では、セキュリティトレーニングを優先的に実施し、ベストプラクティスを日常業務に取り込むことが推奨されます。これにより、設定ミスの削減やインシデント対応時間の短縮を図れる他、進化し続ける脅威に対峙する上で必要な知識や習慣を身につけることが可能となります。実際、SANS Instituteの調査によると、セキュリティ意識向上トレーニングを定期的に実施している組織では、インシデントが最大で70%も減少しています。
Telusの報告によると、調査対象企業の中で、クラウド・サイバーセキュリティの専門スタッフがいるのはわずか37%に過ぎませんでした。ISC2の報告では、組織の35%が、クラウドコンピューティング・セキュリティを重大なスキルギャップとして認識していると、述べられています。トレンドマイクロでは2023年に、EUのサイバーセキュリティ専門家を対象とするクラウドセキュリティ調査を行いました。本調査の回答者は、重要スキルとして、クラウドセキュリティに関するさまざまなコンプライアンスや規制要件の理解、多様なクラウド環境でのセキュリティ管理などを挙げました。十分に成熟したチームであれば、こうした課題にも少なからず対処できると考えられます。
DevSecOpsの導入
DevSecOpsは、DevOpsのパイプラインにセキュリティ対策を組み込むアプローチであり、開発の全工程にセキュリティを行き渡らせる効果が期待されます。
DevSecOpsは、迅速な開発と強固なセキュリティの調和に役立ちます。「GitLab 2024 Global DevSecOps Report」の報告によると、調査対象とした開発チームの54%が統合DevSecOpsプラットフォームを導入し、開発効率と運用効果の大幅な向上に繋がりました。DevSecOpsの一環としてCI/CDパイプラインの自動セキュリティチェックや継続的な監視を導入している組織は、1日に複数回デプロイを行っている確率が4倍ほど高く、こうした取り組みの効果がうかがえます。
「Gartner Peer Community」の調査でも、DevSecOpsを採用した組織の66%でセキュリティ・インシデントが減少し、58%でコンプライアンス・スコアが改善しました。
クラウド・コンテナセキュリティの未来像
企業や組織がクラウドやコンテナの利用率を高めていく中で、AIや機械学習（ML）はもはや任意選択の特殊機能などではなく、セキュリティの中枢コンポーネントとして働き始めています。当該技術は、設定ミスに特有のパターンや異常を的確に分析することで、セキュリティリスクの発見に大きく寄与します。また、AIやMLは、発見された問題の修復作業を自動化し、設定のセキュリティ確保に必要な手間を削減する上でも有用です。実際に当該技術はすでにDevSecOpsのツールに取り込まれ、開発ライフサイクルの全体を通じて、設定ミスや脆弱性の自動検知に役立っています。
一方で、AIやMLは新たな課題や複雑さ、セキュリティリスクを引き起こす可能性があるため、その導入にあたっては、十分に注意する必要があります。はじめに、AI・MLツールがクラウド環境内で安全に統合、管理されるように、ガバナンスの枠組みを整備することが重要です。
クラウドベースのシステムやインフラ（例：IaaS、SaaS、PaaS）に潜む設定ミスを修復するためには、多数の手続きを踏む必要があり、その要件も複雑化する傾向にあります。こうした問題に具体的に対処する手段として、最近ではCSPM（Cloud Security Posture Management）ツールを利用する動きが見られます。CSPMツールは、さまざまなクラウド環境の状態を統合的に可視化すると同時に、セキュリティポリシーの自動適用機能を提供します。こうしたツールは、特に複数プロバイダのクラウドサービスを同時利用する組織にとって有益ですが、適切に運用しなければ諸刃の剣となりかねない点に注意する必要があります。
設定ミスのリスクを軽減する手段として、現在では多くの企業や組織がゼロトラストのアーキテクチャを採用しています。Gartnerの報告によると、調査対象としたグローバル・リーダーの63%が、事業運用の一部または全体にゼロトラストの戦略を取り入れています。
ゼロトラストとは、いかなるユーザや端末も、デフォルトでは信頼しない方針を指します。アクセスリクエストについては、それが実際にどこから来ているかは問わず、オープン・ネットワークから来たものと同然に検証を行います。本方針では、ユーザや端末が厳格に識別され、強力な監視体制が敷かれます。そのため、攻撃者にとっては、設定ミスを利用しにくい状況が作られます。
ゼロトラストのアプローチは業界のベストプラクティスとして認知されていますが、企業や組織では、その適用範囲や有効性を注意深く見極めることが推奨されます。例えば、上述したGartnerの報告によると、調査対象とした組織の35%が、本アプローチの適用を妨げるような失敗に遭遇したと、述べています。さらに悪いことに、2026年までには、75%の組織が管理外のレガシーシステムやサイバー・フィジカルシステムをゼロトラスト戦略から除外すると予想されています。理由として、当該システムが業務上重要、かつ特殊なタスクを担っている点が挙げられます。しかし、その特殊な性質ゆえに、設定ミスや脆弱性を抱えやすい傾向にあります。こうした問題に対処する上では、ゼロトラストの原則では管理できない特殊なシステムも含めてクラウド環境やIT環境を保護できる、包括的で適応性の高いセキュリティソリューションが重要な役割を果たすと考えられます。
設定ミスが重大な脆弱性に変貌する可能性
企業や組織がクラウドサービスに移行し、SaaSモデルによるクラウドアプリケーションを利用するに従い、設定ミスが従来型の脆弱性と同等、またはそれ以上の危険性をはらむようになっています。
トレンドマイクロでは2020年当時より、設定ミスがセキュリティ上の脅威になるものと予測していました。言うまでもなく、脆弱性が表舞台から消え去ることはなく、設定ミスとともに猛威を振るうこともあるでしょう。しかし、設定ミスの脅威は、確実に根を張っていくでしょう。こうした課題に対峙する上で、まずクラウド管理者は、セキュリティリスクの存在を常に意識する必要があります。また、セキュリティチームでは、古い技術で稼動しているプラットフォームにも柔軟に適応していく姿勢が求められます。
現在の設定ミスが、明日には重大な脆弱性に発展している可能性があります。こうしたリスクを減らすためにも、企業や組織では、堅牢な設定管理や継続的な監視、セキュリティ自動化などの対策を優先的に実行することが推奨されます。定期的なセキュリティトレーニングやDevSecOpsの実践は、クラウド戦略に不可欠な要素と言えるでしょう。さらに、ゼロトラストの原則やAI・ML技術を効果的に活用し、先手を打つ形で脅威の検知や修復作業を実施することが、セキュリティ体制の改善に繋がります。
参考記事：
Today’s Cloud and Container Misconfigurations Are Tomorrow’s Critical Vulnerabilities
By: Alfredo Oliveria
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）