2016年初頭、Alaska AirlinesのCEOは業界イベントでShieldXの創立者に出会い、タルバート氏とShieldXの担当者とのミーティングを設けた。タルバート氏にとって、ShieldX製品のアーキテクチャは印象深かったという。

　ShieldXをはじめ、vArmour Networks、Illumioなどのセキュリティベンダーは、ネットワークを細かく分割する「マイクロセグメンテーション」によって、アプリケーションのセキュリティを強化するアプローチを採用する。これはファイアウォールによる「防護壁」を強化し、データセンターやその内部にあるアプリケーションを保護する、境界に基づく従来型セキュリティモデルとは大きく異なる。

　クラウドネイティブのアプリケーションが、サーバやデータセンターという存在から切り離されることが増えれば、「これまでのセキュリティモデルは変更を余儀なくされるだろう」とタルバート氏は予測する。

　タルバート氏は「まずShieldXに当社のレガシー環境を理解してもらうことで、レガシーデータセンターから新しいデータセンターへの移行を安全に進めることができた」と話す。クラウド内のものも含め、アプリケーションを新しいデータセンターに移行すると、その移行に関連する工程を表すパイプライン（一連の処理）に「タグ」が付けられる。それによりアプリケーションをどこに配置しても、あらかじめ設定したポリシーを自動適用できる。

　このタグシステムの設計では、Alaska AirlinesのエンジニアがShieldXを支援した。このシステムにより、アプリケーション開発者はファイアウォールのポートやルールの複雑な情報を意識する必要がなくなったという。Alaska Airlinesの情報セキュリティ部門が入力したポリシーも自動的に反映されるため、各アプリケーションの導入前に実装を検討する必要もない。

　タグシステムの導入以前、Alaska AirlinesのITチームはアプリケーションのセキュリティポリシーをファイアウォールに適用するのに最大2週間かけていた。それが今では数秒から数分に短縮できている。

　タルバート氏が製品を選定した当時、ITに精通していないAlaska Airlinesの関係者にとって、このタグシステムのシンプルさがShieldXの大きなメリットだったという。「アプリケーションが複雑になるほど、何かを見逃す機会が増え、セキュリティは脆弱になる」というのが同氏の考えだ。

コンテナ活用の未来

　コンテナを使ったインフラに対するShieldXの支援は、まだ開発途上だ。同社のCEO、ラティンダ・アフジャ氏によると、同社はマイクロサービスアーキテクチャ向けのサービスメッシュ（サービス間のデータ連携を処理する仕組み）構築ツール「Istio」と、コンテナで動作するプロキシ「Envoy」を利用し、コンテナ向けのDevOpsセキュリティ製品の開発を計画している。

　Alaska Airlinesは、MicrosoftのマネージドKubernetes「Azure Kubernetes Service」（AKS）を利用して、クラウドとオンプレミス両方でKubernetesおよびコンテナを運用している。Alaska Airlinesのアプリケーションにおけるコンテナ関連の処理は、大半がテストと開発に起因する。実稼働しているアプリケーションのうちコンテナで運用されているのは、重要度の低い少数のアプリケーションだけだ。同社はコンテナでの運用について予備調査をしている段階であるものの、全面導入について検討中だ。「ShieldXが当社と同じ方向に進んでくれることを期待している」（タルバート氏）

　ShieldX製品でコンテナを扱えるようにした後、将来的にはセキュリティポリシーの自動適用を従業員のPCなどのエッジデバイスまで拡張することがタルバート氏の狙いだ。それまで同氏のチームは、エッジデバイスやデータセンターへの攻撃をShieldX製品が捉えられるようにするため、ShieldXが提供するAPIを使って、Carbon Black製品などのエッジデバイス向けセキュリティツールを導入する計画を進めている。