コンテンツに移動
セキュリティ & アイデンティティ

クラウド トランスフォーメーションを成功させるには組織風土の変革が鍵

2022年11月15日
https://storage.googleapis.com/gweb-cloudblog-publish/images/cybersecurity_action_team_jl2RU0c.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2022 年 11 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

約 20 年前、さまざまな組織においてサーバー仮想化の有用性が認識されるようになりました。数ある利点のうちでも特筆すべき点は、仮想化によってアプリケーションごとに物理サーバーを用意する必要がなくなり、ソフトウェア定義のインフラストラクチャを管理する時代が始まったことでした。仮想化によってシステム構築とインストールの自動化が進み今日の継続的インテグレーション / 継続的デリバリー(CI / CD)のメカニズムや DevOps の実践の基盤が作られました。しかし、仮想化の手法が定着するまでの道のりは必ずしも平坦ではなく、さまざまな障壁が立ちはだかりました。今日、クラウドへの移行において、組織はこれと同様の困難に直面しています。  

サーバー環境の仮想化を進めようとした組織が 20 年前に直面した非常に大きな課題とは、技術的なものでも資金的なものでもなく、IT チームの内外に横たわる組織的なものでした。初めにサーバー仮想化の影響を受けたのは、物理サーバーをデータセンターのラックへ設置し、物理的なネットワーク接続を管理し、暖房換気空調システムや電源システムなどの環境制御を行っていたチームでした。こうしたタスクは完全にゼロにならなかったとしても、劇的に減少しました。

次に影響を受けたのは、オペレーティング システムのインストール作業とインストール後の手順を担っていたチームでした。仮想マシンはほとんどの場合、テンプレートから自動でインスタンス化されるため、こうした業務もほぼ消滅しました。 

つまり、仮想化の導入が成功するかどうかは、このような組織の変革が円滑に進むかどうかにかかっていたのです。また並行して、仮想インフラストラクチャの運用に必要な新しいスキルに関する研修をスタッフに実施することも欠かせませんでした。そして、仮想化導入の影響を受けたチームの多くは、新しい業務が従来とは異なっていても組織にとって不可欠なものであることや、これまで以上に面白いものかもしれないことに気付いたのです。

仮想化の教訓を活かした規制下のクラウド トランスフォーメーション

各種規制の影響下で稼働する組織の場合、仮想化にあたっては組織内の変革を検討するだけではなく、規制当局とも密接な連携を取る必要がありました。このような組織では、ハイパーバイザとは単に脆弱性のリスクを持つソフトウェア レイヤを 1 層追加するものだという認識がしばしばありました。

こうした観点からは物理サーバーでは存在しなかったリスク(仮想マシン エスケープなど)が懸念事項として挙げられました。仮にこうしたリスクが考慮され緩和されるとしても、マシンの仮想化によるすべての利点(アセットの識別、ハーモナイゼーション、より円滑なパッチ管理などのセキュリティ上の利点も含む)は、このリスクと秤に掛けたうえで検討しなければならないものでした。

仮想化の適切性や利点は現在では広く受け入れられていますが、クラウド移行に際して現在の組織で生じる問題は当時とよく似ています。大手のクラウド サービス プロバイダ(CSP)がお客様の重要なワークロードのサポートを行うようになり、これに伴って規制当局は CSP への監視を強化し、クラウド導入についてのガイダンスを発行しています。すでに欧州の金融セクターでは規制が行われており、欧州監査当局(欧州銀行監督局欧州証券市場監督局欧州保険・企業年金監督局)からガイドラインが発行されたほか、デジタル オペレーショナル レジリエンス法も実施が迫っています。

このような規制は、プロバイダとお客様の間に信頼関係を築くうえで役立つものです。組織にとっては、これらの規制当局の決定は非常に重要なものであり、この機会に、クラウド技術の活用でリスクと利点のバランスを取ることについて、また組織全体がセキュリティ レベルとコンプライアンス レベルを向上させるために、CSP の提供するあらゆる支援をどのように活かせるのか、検討することもできるでしょう。

組織風土の変革がクラウド トランスフォーメーションを促進

クラウド トランスフォーメーションとサーバー仮想化のもうひとつの類似点は、内部の変革が必須だという点です。組織がクラウド移行に着手することを決めた場合、新技術やツールに関するスタッフの研修はもちろん必要なステップですが、必ずしも最優先事項ではありません。また最も困難な事項とも限りません。特にセキュリティ上の観点から見ると、クラウドの利点をフル活用するためには、意識の変革こそが最も重要です。

組織レベルでの抜本的変革があってはじめて、クラウド移行へのアプローチはスタートを切ります。クラウドはデータセンターとしてとらえるべきではありません。クラウド技術にはそれ以上の多様な可能性があるからです。クラウド移行へのアプローチとそれに伴う組織変革を進める原動力は 2 つあります。1 つめは、CSP によってお客様の負担が軽減されることです。2 つめは、ソフトウェア定義のインフラストラクチャが新たな柔軟性をもたらすことです。

CSP は、複数のタスクやサービスとそのセキュリティを直接管理します。つまり、この部分はお客様にとって直接の懸念事項ではなくなります。データセンターの管理、ハードウェアのセキュリティ堅牢化、保存データおよび転送中のデータのデフォルトでの暗号化、レジリエントなネットワーク管理などは、CSP が担当します。

組織がワークロードを管理するためのインフラストラクチャは、すべてソフトウェア定義となるため、より柔軟な使い方が可能になります。ソフトウェア定義のインフラストラクチャは、セキュリティ対策の有効化がより容易で、また従来とは異なり継続的な基準適合が可能です

組織のクラウド移行は、オンプレミス インフラストラクチャからの単なる「リフト&シフト」作業としてとらえれば良いように思われます。しかし実際には、こうしたアプローチではクラウド トランスフォーメーションが組織へもたらす利点のうち一部しか得ることができません。クラウドへのシステム移行は、クラウドの導入で生じる影響のうちのごく一部です。意識の更新こそが真の変革です。開発、アーキテクチャ、セキュリティ プロセスの再構築が求められるため、必然的に深いレベルでの組織変革が必要になります。

次に行うのは、運用の変革です。組織全体と新しく定義されたプロセスに運用を適合させ、CI / CD を運用可能にし、DevOps のプラクティスを構築します。その後、技術的な不足部分を解消します。新しいツールへ移行し、最適な使用方法をチーム内へ共有します。

ここで大切なのは管理すべき変革の順序です。まず組織、次に運用、それから技術の順序であって、この逆順ではありません。もちろん、技術は組織や運用において重要な役割を担うため、この 3 段階は完全に順番付けできるものではありません。それでも、変革の機会を最大限活用するためには、まずツールに注力するのではなく、組織メンバーの変革やフレームワークの開発をサポートすることが欠かせません。   

さらに、Google Cloud では責任の共有という従来のモデルからさらに進んだ、運命の共有という考え方を掲げています。お客様の責任範囲における目標の達成に向けて支援していくことも Google の任務であると考えています。安全な着地点を提供し、お客様をご案内し、セキュリティ制御にあたっては透明性を実現し、サイバー保険で支えます。

継続的なセキュリティの向上は、お客様と Google の共通の目標です。Google サイバーセキュリティ対応チームの取り組みにより、お客様に寄り添い、必要なガイダンスを提供し、セキュリティとコンプライアンス戦略の面からお客様を支えて、お客様のクラウド移行のための組織変革と運用変革をお手伝いします。

  

- CISO オフィス ディレクター、Thiébaut Meyer
- CISO オフィス セキュリティ リーダー、Tony Richards

投稿先