月別アーカイブ: 2021年2月

認証基盤のモダン化とCASBのValue

三井情報株式会社
橋本 知典

今回は、企業のデジタルトランスフォーメーション(DX)に必要な認証基盤のモダン化とCASBのValueについて説明していく。

■2025年の崖

経済産業省が2018年に公表した「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」では、DXの実現ができない場合、2025年以降最大12兆円の経済損失が生じる可能性があると推定している。2020年は新型コロナウイルスの影響でテレワークが必要になり、セキュリティ対策の不備等、企業は環境に合わせて自社のビジネスを迅速に変革しなければ生き残ることができない問題に直面した。この問題は正に「2025年の崖」問題の先触れといえる。

企業は、DXに取り組むことが求められているが、DX推進に向けた大きな課題としてレガシーシステムの刷新がある。2025年には21年以上の基幹系システムを抱える企業が6割を超える。レガシーシステムを刷新しない場合、保守切れのシステムが増え、保守運用費のコストが大きくなる。またIT人材が不足していくと予想され、多くの技術的問題を抱え、運用が困難になることが想定される。さらに、システムのサポート終了などにより、障害によるシステムトラブル、サイバー攻撃によるデータ流出等のリスクが高まる。

図1 2025年の崖

2020年12月には、経済産業省からデジタルトランスフォーメーション(DX)の加速に向けた研究会の中間報告書「DXレポート2(中間取りまとめ)」が公表された。国内223企業がDX推進状況を自己診断した結果、2020年10月時点で9割以上が未着手や一部での実施の状況であり、想定以上に進捗が悪いことが判明した。

【引用元】
DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DXレポート2(中間取りまとめ)』
https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html

■認証基盤のモダン化

「2025年の崖」問題に対する打開策としては、基幹系システムなどをクラウドサービスにマイグレーションすることである。クラウドサービスを活用することで、時間や手間をかけずに基幹システムを移行でき、業務標準化による生産性向上やコストの削減を容易に実現することができる。政府から「クラウド・バイ・デフォルト原則」の方針が出て、クラウドサービスの利用に主軸を置いたITモダナイゼーションが進められ、クラウドの信頼性も大幅に向上してきている現在であれば、安心して移行できるだろう。

クラウドサービスにマイグレーションした場合、IDの認証の連携先としてSAMLなどの認証プロトコルに対応した認証基盤が必要である。多くの企業は認証基盤にオンプレミスのActive Directory(AD)を利用しているが、AD単体ではクラウドサービスとの連携ができない。

また、昨今のサイバー攻撃の多様化・高度化により社内であっても安全とは言えず、オンプレミス環境は徐々にリスクが高まっている。特にランサムウェアは従来型とは変わってきており、企業に搾取した情報を公開すると脅し、高額の身代金を要求する暴露型のものが増えてきた。実際にADの乗っ取りや個人情報が漏えいした事例もある。サイバー攻撃を検知するにもオンプレミス環境では対策ソリューションの導入コストや運用負荷が大きくなる。

これらの課題に対し、認証基盤をモダン化することで解決ができる。クラウド認証基盤であれば、クラウドサービスとも連携でき、サイバー攻撃対策の強化やクラウドサービス毎のIDを一元管理することができるなど、セキュリティ面でも対策を進めることができる。また、境界ネットワークがなくなり、いつでも、どこからでも安全にシステムが利用可能になり利便性も向上する。

図2 認証基盤のモダン化

■CASBのValue

認証基盤のモダン化が進むと、基幹系システムや多くのオンプレミスのシステムがクラウドへ移行しやすくなる。そして最終的にはオンプレミスのシステムを無くすことができ、システムの全てをクラウドサービスに移行する企業も増えてくる。そこで新たな問題として、複数のクラウドサービスの管理やセキュリティが課題になる。クラウドサービスへの統一した組織のセキュリティポリシーの適用やガバナンスの強化が必要になるだろう。

CASBは企業でクラウドサービスの活用が増えるほど真価を発揮する。もしクラウドサービス毎にセキュリティ対策を個別で行った場合、コストが高額になってしまう。CASBを導入すれば複数のクラウドサービスに対し、CASBのコストのみでセキュリティ対策が可能になる。また、CASBでは一つの管理画面から連携しているクラウドサービスのポリシー設定が可能であり、統一したポリシー管理が可能である。他にも、クラウド認証基盤と連携することで、リバースプロキシアーキテクチャによりエージェントレスで、連携したクラウドサービス内のファイルダウンロードなどのアクティビティに対し、リアルタイムでセッション制御が可能になる。例えば、社給端末以外からクラウドサービスのファイルの閲覧はできるが、機密情報のファイルのダウンロードをできないように制御が行えるなど、高度な情報漏洩対策ができる。このようにコスト面・管理面・セキュリティ面でもCASBのValueはさらに上がっていくことが想定される。

以上のように、企業は「2025年の崖」問題の対策として、認証基盤のモダン化を行い、基幹システムをクラウドサービスに刷新していくことでDXを促進できるだろう。そしてクラウドセキュリティ対策として今一度CASBの活用を検討してみてはどうだろうか。

〈お断り〉
本稿の内容は著者の個人的見解であり、所属企業・団体及びその業務と関係するものではありません。

クラウドコンピューティングの進化と新たな責任共有モデル

本ブログは、Vishwas Manral, Founder and CEO at NanoSec, CSA Silicon Valley Chapter のブログ(The Evolution of Cloud Computing and the Updated Shared Responsibility、https://cloudsecurityalliance.org/blog/2021/02/04/the-evolution-of-cloud-computing-and-the-updated-shared-responsibility/)の日本語版で、著者の許可のもとに翻訳し公開するものです。原文と日本語版の内容に相違があった場合には、原文が優先されます。

 

クラウドコンピューティングは、過去10年間変化し続けてきた。このブログは、コンテナ、機能、ローコード、ノーコードの成長によるクラウド状況の変化の結果として、今までのサービスモデルがもはや十分ではないということの理由について説明する。

このブログでは、さまざまなパラダイムの責任共有モデルについても説明し、将来の方向性について検討する。

サービスモデル(SaaS, PaaS, IaaS)の背景

米国国立標準技術研究所(NIST)は、2011年に、3つのサービスモデル、4つの配備モデル、5つの主な特性で構成されるクラウドコンピューティングの定義を提供した(NIST Special Publication800-145)。

このドキュメントは、特にクラウドサービスとクラウド配備戦略を比較する際に、その標準とガイドラインを提供する手段として機能し、クラウドコンピューティングの最適な使用法のベースラインを提供することを目的とした。

3つのサービスモデルは、SaaS(Software-as-a-Service)、PaaS(Platform-as-a-Service)、IaaS(Infrastructure-as-a-service)である。これはすでに過去のことであり、モデルは新しいプラットフォームを包含するように進化する必要がある。

重要な変化の推進力としてのイノベーションとソフトウェア開発

市場に新しく差別化された価値をもたらすことは今や競争上の必要性であり、反復可能な方法でより迅速にイノベーションを実現するために最も組織化された企業が市場のリーダーとなる。企業におけるクラウドコンピューティングの配備は、成熟し、変化を遂げており、新しい価値をもたらし、ソフトウェアが変化の原動力となっている。

このことは、インフラストラクチャ層、サービス層、アプリケーション層に当てはまる。ここでは、急増するコンテナ、Kubernetes(K8s)の台頭、エッジコンピューティングの出現、サーバーレスアーキテクチャの幅広い採用を見ることができる。開発者に提供されるすべてのサービスが、より早く市場に価値をもたらすことを可能にしている。

新しいアーキテクチャを2011年のSaaS-PaaS-IaaSフレームワークに適合させようとすることは、丸い穴に四角いペグを適合させるようなものだ。

新しいサービスモデル

中核となるのは、*クラウド*責任共有モデルが、クラウドプロバイダ(Amazon Web Services、Microsoft Azure、Google Cloud Platform、あるいはより総称的にプラットフォームプロバイダ)とクラウド利用者またはアプリケーション所有者(エンタープライズおよびスタートアップ)の間の責任の明確な境界を提供する。

次の図は、さまざまなサービスモデル間における責任の違いを示している。

いくつかの重要なポイント:

徐々により多くの責任がプラットフォームプロバイダによって引き受けられ、アプリケーション所有者をアプリケーションロジック以外の責任から解放している。

右に移動していくと、プラットフォームプロバイダがより多くの責任を負うため、運用コストとオーバーヘッドが削減される。

NoCode/SaaSのようなプラットフォームになると、開発者の責任自体が縮小する。筋金入りのプログラマではない開発者という新しいレベルの台頭につながっている。

IaaS、PaaS、SaaSに加えて、それ以降に進化した新しいサービスモデルを以下に定義する。

Managed K8s as a Service (K8s-aaS)

Managed Kubernetesは、ほとんどのクラウドプロバイダによって提供されるサービスとして最も広く使用されているManaged Service Control Plane as a service(CPaaS)である。ここでは、Kubernetesコントロールプレーンはプラットフォームプロバイダによって管理され、アプリケーション所有者がオプションで提供するコントロールプレーン(別名K8sマスターノード)構成を使用する。データプレーンのライフサイクルとその管理は、アプリケーションの所有者が行う。

これは、アプリケーションにデータプレーンからの特定のニーズがある場合、追加の運用オーバーヘッドよりもコスト最適なスケールアウトが大きな考慮事項である場合、あるいはアプリケーションがマルチクラウドに移植可能なアプリケーションであることが必要な場合に最適である。

例としては、Amazon Elastic Kubernetes Service(EKS)、Azure Kubernetes Service(AKS)、Google Kubernetes Engine(GKE)がある。AWS Elastic Compute Service(ECS)は、Kubernetes以外のマネージドコントロールプレーンサービスの例である。

Container-as-a-Service (CaaS)

CaaSの場合、アプリケーションの所有者がアプリケーションコンテナを提供し、プラットフォームプロバイダがコントロールプレーンとデータプレーンの両方を管理する。つまり、アプリケーションユーザは、CPaaSによって提供されるすべての機能に加えて、サーバー(VM)、ホストOSのスケーリングとパッチ適用、サーバーの起動と停止を管理する必要がなくなる。

これらのサービスは、アプリケーションの所有者が多くのサーバー管理の責任から解放されるため、サーバレスとも呼ばれる。このサービスは、イベントドリブンアーキテクチャではなく、アプリケーションの所有者がスケールアウトのコストをあまり気にしない場合に最適である。

Containers-as-a-Service(CaaS)ソリューションの例としては、Amazon Web Services(AWS)Fargate(ECSFargateとEKSFargateの両方)、Azure Container Instances(ACI)、GoogleCloudRunなどのソリューションがある。

Function-as-a-Service (FaaS)

FaaSの場合、アプリケーションの所有者は、機能を実行するレイヤーとともにビジネスロジックを提供する。これらの機能は、サービスプロバイダによって構築、パッケージ化、および実行される。サービスコントロールプレーンとデータプレーンは、サービスプロバイダによってすべて処理される。

このサービスは、イベント駆動型のステートレスアプリケーションに最適である。

このサービスの例としては、AWS Lambda、Azure Functions、Google CloudFunctionsがある。

NoCode-as-a-Service (NCaaS)

NCaaSでは、コードロジックはアプリケーションの所有者によって提供される。サービスプロバイダは、仕様と構成からコードを生成し、ソフトウェアをビルド、パッケージ化、および実行する。

これと似ているがわずかに異なるもう1つのバージョンは、Low-Code-as-a-Service(LCaaS)である。

コーディングがほとんど必要ないため、これらのプラットフォームは、技術者でないユーザーでもアプリケーションを作成できるように設計されている。これは、今後数年間で驚異的な成長が見られ、ソフトウェア開発者の大幅な増加をもたらす。

このサービスの例としては、Azure Power Apps、Google AppSheet、AWSHoneycodeがある。

Serverless(サーバレス)

サーバレスプラットフォームを使用すると、開発者は開発と配備をより迅速に行うことができ、コンテナクラスタや仮想マシンなどのインフラストラクチャを管理しなくてもクラウドネイティブサービスに簡単に移行できる。

例:上記のモデルでは、CaaS / FaaSおよびNCaaSプラットフォームはサーバレスとして扱われる。

アプリケーションのプラットフォームの選択

次の図は、アプリケーションの所有者がサービスに使用するクラウドプラットフォームを決定する際にその方法の概要を示している。

 

まとめ

まとめると、アプリケーションの将来の展望は非常に多様で、高度にハイブリッドでマルチクラウドである。エンタープライズクラウドコンピューティングプラットフォームには、サーバレスアプリやサーバアプリ、オンプレミス、クラウドなど、さまざまなインフラストラクチャ、サービスレイヤー、APIが含まれる。

「ワンサイズですべてに対応」するモデルや経験則はない。真のクラウド方式においては、組織の変化に応じて進化するスケーラブルでセキュアな環境をサポートするための機敏で弾力的な決定が必要である。