クラウド・ネイティブ・セキュリティとは
クラウドを取り巻く状況は大きく変化している。仮想サーバー単位で利用するIaaS中心の需要が、ミドルウェアあるいはサービス単位で機能を利用するPaaSやSaaSへと急速にシフトしている。
その理由として、Cloud FoundryやDockerに代表されるコンテナ技術の普及と、サービス・ラインナップの充実が挙げられる。現在では、仮想サーバーとミドルウェアのインスタンスを連携させてアプリケーションを容易に構築できる。オンプレミスで稼働していたシステムをIaaSに移行したり、クラウドだけでシステムを新規構築することも、もはや珍しくはない。
クラウド環境を前提に、その特徴を活かして構築するシステムを「クラウド・ネイティブ」と呼ぶ。本稿ではクラウド・ネイティブで考慮すべきセキュリティ機能について、IaaS利用時とPaaS／SaaS利用時のそれぞれで整理し、セキュアなシステム構築のための要件と実現方式を明確にする。
クラウドは、自社で稼働していたシステムをクラウド事業者サイトで稼働させる点が従来との最大の違いであり、主に次の2点からセキュリティ機能を考える。
①システムとユーザーの接続
IT部門（開発者、運用管理者）、社内ユーザー部門（アプリケーション利用者、管理者）、エンドユーザーと、クラウド上のシステムをいかにセキュアに接続するか。
②不正アクセスからの防御
クラウド上のシステムを（オンプレミス同様に）、不正アクセスからどう守るか。
IaaS利用時の
セキュリティの考え方
従来のオンプレミス環境では利用者と物理的・論理的に同じサイトにあったシステムが、IaaSではクラウド事業者の運用するサイトで動作する（図表1）。
システムとユーザーの接続
システムとユーザーの接続には、以下のような対策を採用する例が多い。
A 専用線接続サービスを利用して、インターネットを経由することなく、社内ネットワークをクラウドと接続する
B インターネット経由で接続するが、VPNを利用して、社内ネットワークとクラウド側のプライベートネットワークを接続する
C インターネット経由で、TLSなどにより暗号化して、クラウド側のパブリックネットワークと接続する
A＞B＞Cの順でコストが高く、セキュリティ強度も高い。AやBはクラウド事業者によって実装可否が分かれ、採用できない合もある。ネットワーク間接続について、顧客がAやBのセキュリティレベルを要求する場合、クラウド事業者に提供可能かどうかを早い段階で確認する。
不正アクセスからの防御
不正アクセスからの防御については、クラウド事業者の提供するセキュリティ機能や製品を利用してFirewall、WAF、IPS／IDSなどを実装したり、クラウド事業者のパッチサイトから定期的にセキュリティパッチを適用するなどの対策を立てる。物理層やハイパーバイザ層のセキュリティ対策は事業者に任せることになる。
この点でも、事業者のセキュリティ対策、セキュリティ認証取得の有無、利用可能なセキュリティ製品を確認し、メニューとして提供されていない場合は自前で構築できるかどうかがポイントとなる。
PaaS／SaaS利用時の
セキュリティの考え方
PaaS／SaaSを組み合わせて実装するシステムでは、登場するコンポーネントやアクター（登場人物）がより多様化し、複雑になる（図表2）。
自社システムは全体の一部となり、いろいろなベンダーのPaaSやSaaSを必要に応じて組み合わせて利用する。機能単位で考え、それぞれの稼働する場所は別々になる。また、それらを利用するユーザーのアクセス経路も多様になる。
開発や運用を他社に依頼した場合、従来は各ベンダーのメンバーが顧客サイトあるいは専用のプロジェクトルームに集まって作業する形態が中心だった。しかし今はそれぞれのメンバーが自社サイトから直接顧客のクラウド環境にアクセスし、作業するケースが増えている。
システムとユーザーの接続
物理的に複数の作業拠点と複数のクラウド事業者サイトを、それぞれ専用線で接続するのは現実的ではない。またPaaS／SaaSでは、利用可能な（利用者に開放されている）接続方式がWebのGUIかAPIに限られることが多い。前出のAは選択肢から除外し、Bはユースケースにより適用可否が分かれる。
物理層からTCP/IP層で、一律にセキュアなネットワーク領域を担保できない場合、システムの境界（アクセス可否）は、より上位層で接続するインターフェースの種類ごとに考える必要がある。
各種クラウドサービスが提供するWeb GUIには一般に、サービスの機能そのものを利用するための「（1）アプリケーションGUI」と「（2）運用管理用GUI」がある。前者はアプリケーションを利用する社内外のユーザー、後者はシステムの開発・運用管理の担当者が利用する（図表3）。
（1）アプリケーションGUIのユーザー認証認可
GUIをセキュアに利用するには、ユーザーの認証と認可機能を実装し、正しいユーザーに適切なアクセス権限を与える必要がある。PaaS／SaaSを利用する複雑な環境下では、認証情報がアプリケーションごとに散らばり、ユーザーが多数の認証情報を登録・管理するため煩雑になる（ただしこれはクラウドに限らず、これまでも課題となってきた）。
オンプレミスやIaaSのネットワークで境界を作れるシステムでは、認証認可機能を統合認証システムとして集約・実装し、ユーザーとアプリケーションの間に配置することで、利便性を損うことなくセキュリティを担保してきた。
一方、PaaS／SaaSを組み合わせるクラウド・ネイティブでは、ネットワークによりシステム境界を作れないので、認証基盤を同じようには配置できない。そこでは、認証連携を実現する「フェデレーション」と呼ばれる技術が有効に機能する（図表4）。
フェデレーションプロトコルにより、ユーザーは1カ所でのみ認証すれば、複数のアプリケーションへのアクセスが可能となる。フェデレーションを実装する代表的なプロトコルには、SAMLとOpenIDConnectの2つが挙げられる。
SAMLは企業向けクラウドで普及している。一方、コンシューマー向けSaaS（SNSを含む）では、JWTトークンのプログラムの使い勝手がよいせいか、OpenIDConnectのほうが普及しつつある。コンシューマー向けSaaSがビジネス利用機能を充実させるのに伴い、企業でもSAMLだけでなく、OpenIDConnectによる認証連携を実装するケースが増えている。
つまり、PaaS／SaaSを活用してシステムを構築する場合には、認証認可情報をどこに配置し、どう連携させるかを設計に反映させる必要がある。
（2）運用管理用GUIのユーザー認証認可
システムの開発者や運用開発者に必要なインターフェースには、クラウド上のリソースを管理するための管理コンソールあるいはダッシュボードと呼ばれるGUI、あるいはOSやミドルウェアにログインして作業するためのインターフェース（SSHログインなど）がある。
管理コンソールでは一般に、ユーザー認証機能と管理操作権限の制御機能も提供しており、また画面上で実行できる管理操作をコマンドラインから呼び出すAPIを準備している場合も多い。
具体的な実装は事業者により異なるので、複数のサービスを利用する場合は、それぞれの仕様を確認したうえで、開発環境管理や運用管理の方針に沿って実装ルールやネーミングの体系を事前に決めておくことが望ましい。
たとえばIBM Cloudではクラウド上のリソースを定義してアクセス制御を行えるが、開発者や運用者の体制を踏まえて、どのような単位でのアクセス制御が必要かを事前に検討したうえでリソースやリソースグループを定義する必要がある。AWSでも同様に、リソースの種類と実施したい操作（アクション）を設計する必要がある。こういった事前のリソースと権限の設計がないまま使い始めると、規模が拡大したときに運用負荷の高いシステムになり、軌道修正に余分な時間と労力を要する。
管理コンソールのユーザー認証は、IBM CloudやAWSでフェデレーション機能を実装可能である。複数の管理コンソールを使用する場合には、開発・運用管理でもフェデレーションを活用できる（図表5）。
サービスそのものの管理以外、つまりOSやミドルウェアへログインする作業の認証認可は、従来どおりOSやミドルウェアの備えるユーザー認証認可機能を利用することになる。この際に最も重要なのはID／パスワード、SSH鍵認証の鍵ファイル、APIキーなどの認証情報を安全に保管し、管理することである。エンドポイント側から認証情報が漏洩しないよう機密レベルの高いデータとして扱う、パブリッククラウド上で不用意に保管しないといったルールの整備と徹底が必要である。
不正アクセスからの防御
IaaSでは物理セキュリティのみを事業者に任せるが、PaaS／SaaSではFirewall、IDS／IPS、パッチなど、広範囲なセキュリティ機能を事業者に依存することになる。とくにSaaSでは、利用者側で実施するのは前述したユーザー認証認可に関する情報のクライアント側での取り扱いと、管理コンソール上での権限管理のみである。
IaaS、PaaS、SaaSを組み合わせる場合には、利用者側で実装すべきセキュリティ機能がそれぞれ異なることを意識し、どこにどのようなセキュリティ実装が必要なのか、漏れがないよう設計・実装・管理していくことが重要である。
クラウド・ネイティブ固有の要件
ここまで従来システムにも共通するセキュリティ要件の考え方を解説してきたが、既存のITセキュリティポリシーやルールでは、クラウド・ネイティブの仕組みに対応できないケースがあり、注意が必要である。
従来のオンプレミスシステムを念頭に作成し、そのまま更新していない場合、クラウドならではの実装方式に対して適用が難しい規定や意味のない規定があり、判断に困ることがある。
たとえばサーバーの起動時にOS、ミドルウェア、アプリケーション、各ソフトウェアの最新バージョンを動的に組み込み、設定のカスタマイズはスクリプト化して、起動のたびに実行する実装や、サーバーレス・アーキテクチャと呼ばれる実行環境だけを利用するサービスを考えてみる。
これらの実装では、インスタンスへの定期的なセキュリティパッチ適用は不要だが、起動時に実行される処理にセキュリティ要件を満たす設定や処理を組み込む必要がある。また動的かつ自動的に組み込まれるソフトウェアや設定値の保管場所へのアクセス制御がより重要になる。
こういったクラウド特有の実装方法を含め、システム全体のセキュリティ機能を包括的に管理する手法や仕組みは、まだ整備途上にある。マルチクラウド、ハイブリッドクラウドといった多様な環境では、利用者自身が設計の初期段階からセキュリティ機能、とくに認証認可の枠組みを検討することが求められる。
クラウドベースのシステムは多様であり、利用形態に応じて利用者側が考慮すべきセキュリティ機能の実装には違いがある。同じセキュリティレベルが担保できるよう、それぞれの機能を明確にし、同等の実装となるよう留意する。
多様で複雑な組み合わせが管理の不備を招き、セキュリティホールを形成することのないよう、設計段階から効率的かつ持続的な運用を可能にするセキュリティを考える必要がある。
著者｜酒井美香
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・ソリューション セキュリティー
コンサルティングITスペシャリスト CISSP
入社以来、ユーザーID管理・アクセス制御製品の技術支援を担当し、金融を中心に、さまざまな業種のユーザープロジェクトに参画。近年はクラウド環境、IoT、制御系ネットワークなどのセキュリティを手がけている。日本ネットワークセキュリティー協会（JNSA）IoT Security WGメンバーとして活動中。
