クラウド・セキュリティー

DX時代のクラウド・セキュリティー: クラウド第2章をセキュアにせよ〜Secure the Chapter 2〜 Vol. 1

2020-05-07

記事をシェアする:

クラウド第2章

デジタル変革(DX)の必要性が叫ばれる中、クラウドの活用が広がっています。

これまでのクラウド活用はクラウドで提供されるサービス (SaaS)の利用や既存システムをクラウド基盤 (IaaS) で稼働させる形態が中心でした。しかしながらデジタル変革の実現のために、より積極的なクラウド・テクノロジーの採用の必要性が認識されるようになってきました。これらの技術はクラウド・ネイティブ技術と呼ばれ、以下のような技術を積極的に活用することでアプリケーション開発・リソースの高速化やインフラ構築・運用・管理の自動化が実現することが期待されています。

コンテナとコンテナ・オーケストレーター(Kubernetes)
イミュータブル・インフラストラクチャー
マイクロサービス

またクラウドで利用されるシステムの質の変化も指摘されています。クラウドがお客様との最重要接点となり、企業の重要データと結びついて稼働するようになる、いわゆるミッション・クリティカルな性質が求められるようになります。社会インフラとして高い可用性が求められる一方で、お客様の個人情報など高い機密性が求められる情報が扱われるようになります。

システムの形態も複雑なものに進化していきます。オンプレミスにあるシステムとの連携、いわゆるハイブリッド・クラウドが常態化し、複数のクラウドベンダー上でシステムが稼働するマルチクラウドも進んでいくでしょう。

IBMではこれらの変化を総称してクラウド第2章と呼んでいます。

オープンなプラットフォームの必要性

IBMはクラウド第2章を支えるプラットフォームはオープンなものでなければならないと考えています。オープンであることによって、オープンソース・コミュニティーが提供するイノベーションを迅速に自社で活用することができるようになります。またオープン化されたプラットフォームを利用することでハイブリッド・マルチクラウドの環境でのアプリケーションの可搬性が保たれ、一元的な管理が可能になっていきます。

IBMはCNCFを中心としたオープンソース・コミュニティーに積極的に関与するとともに、Red Hatとの協業により、企業向けKubernetesであるOpenShift を中心としたオープンなプラットフォームの構築を推進しています。

事業継続の観点でもオープンであることは重要な意味を持ちます。 IaaSではデータセンターやハードウェア・インフラストラクチャーの部分はクラウド・ベンダーの提供するサービスに依存することになりますし、PaaS、SaaSを使用する場合にはさらに依存度が高くなります。クラウドベンダーは利用企業が統制を及ぼすことができない第三者であり、重要なシステムを過度にベンダー依存することは事業継続に影響を与える可能性があります。アプリケーション・プログラムやデータなどの企業固有のシステム資産の可搬性を確保し、いざという場合には他のクラウド環境に移行できるような考慮が必要になります。事業継続の観点からオープン性、可搬性をどのように確保するかは今後クラウド適用戦略を考える上での大きなアーキテクチャーを決定する際の検討課題になっていくものと考えられます。

クラウド・ネイティブ環境へのセキュリティーの適用

それではクラウド第2章でのセキュリティーには何が求められるでしょうか。まずクラウド・ネイティブ環境にセキュリティーを適用する場合の考慮点について検討します。

以下の図はそれぞれのレイヤーに対してセキュリティー対策として検討すべき事項を例示したものです。

これまでセキュリティーの検討に携わってこられた方にとっては、これらの項目自体はさほど新しいものはないかもしれません。しかしながらコンテナ・オーケストレーター (Kubernetes) を中心とするクラウド・ネイティブ環境には以下のような特徴があり、これらに対応したセキュリティー技術を選択し、適用する必要が出てきます。

通信制御、負荷分散機能等のソフトウェア・コンポーネント化

Kubernetes環境内では、通信はKubernetes基盤で実装されるSoftware Defined Network (SDN)によって制御されます。また従来は物理サーバー上で稼働していた負荷分散機能やプロキシー機能がKubernetes上のソフトウェア定義によって提供されます。ファイアウォール、IPS/IDS、プロキシーなど従来ネットワーク・アプライアンスとして提供されることが多かったこれらの機能の実装と配置を見直す必要があります。

コンテナ化されたソフトウェア・コンポーネントが動的に稼働・停止・拡張

この特徴によって負荷の変化に動的に対応することができますが、IPアドレスが自動的に付加され増加したり消滅したりするために、従来型のファイアウォールに代表されるようにIPアドレスを元にしたセキュリティー制御が難しくなります。

アプリケーション開発とデプロイの自動化。頻繁なリリースの実施

アプリケーション・リリースの高速化の目的のために、CI/CD（Continuous Integration / Continuous Delivery）ツールが利用され、コンテナ化されたアプリケーションのコード・ビルド・デプロイが自動化される環境ができることになります。アプリケーションおよびコンテナの脆弱性対応をこの自動化プロセスの中に組み込んでいく戦略が求められます。

APIによる制御

コンテナ化されたコンポーネントはその振る舞いがAPIによって制御されるようになります。従来セキュリティー設定の確認、コンプライアンス準拠などのセキュリティー・ポリシーの制御はそれぞれのサーバー機器あるいはサーバー上のソフトウェアに対して個別に実施されていましたが、これらもAPIによって実施されることになります。APIによる自動化、統合管理が可能になるため、管理の一元化や徹底を実現する方策を検討することが必要となります。また操作管理を実施するAPIに対してどのように認証認可を実施するかも新たな検討対象となります。

当稿Vol. 1ではクラウド・ネイティブ環境にセキュリティーを適用する際の総論的な考慮点を取り上げました。Vol. 2以降ではハイブリッド・マルチクラウド環境へのセキュリティー対策の適用についてより具体的にご紹介いたします。

【関連情報】

IBM クラウド・セキュリティー・ソリューションの概要

【お問い合わせ】

日本アイ・ビー・エム株式会社セキュリティー事業本部コンサルティング＆システム・インテグレーションシニア・アーキテクト吉田浩司まで、メールにてお問い合わせください。

【著者情報】

吉田浩司
日本アイ・ビー・エム株式会社
セキュリティー事業本部
コンサルティング＆システム・インテグレーション
シニア・アーキテクト
CISSP

1985年に日本アイ・ビー・エム株式会社に入社。お客様担当システムズエンジニアとし活動後、2001年よりセキュリティー技術に関わるコンサルティング活動を実施。その後インフラ・アーキテクトおよびセキュリティー・アーキテクトとして活動し、大規模ミッションクリティカルかつ高セキュリティを求められるシステム構築プロジェクトに参画。数々の金融機関や公共機関のモダナイゼーションプロジェクトやセキュリティー構築プロジェクトにおけるアーキテクトを務める。