ブログ

すべてが安全な時代のスケール

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2016 年 7 月 7 日公開

6 月に開催された Apple の WWDC (World Wide Developer Conference) で、モバイル業界の大御所は、2017 年 1 月 1 日以降、アプリ ストア内のすべてのアプリで App Transport Security (ATS) を使用する必要がある (これは、ネットワーク担当者にとって RFC スタイルの必須事項です) と発表しました。

基本的に、アプリは HTTP ではなく HTTPS を使用するように強制されます。

さて、これが人々にとって何を意味するかというと、彼らには以下のことがわずか数か月でできるということです。

  1. モバイルアプリを更新する
    これは明らかなようです。 結局のところ、iOS 上のモバイル アプリでは HTTPS を使用する必要があるのです。 そうですね、そういうことです。
  2. バックエンドでHTTPSをサポート
    これはあまり明白ではないかもしれませんが、HTTPS の全体的な目的は、少なくとも 2 つの当事者が関与する通信を保護することです。 モバイル アプリの場合、これはオンプレミスまたはクラウド内の何らかのエンドポイント (アプリ、サービス、API ゲートウェイ) です。 これも HTTPS をサポートする必要があります。

2 番目の要件は、スイッチを切り替えるだけの単純なものではないため、技術的にも運用的にも最初の要件よりも複雑です。 証明書とキーの管理、配布、アップグレード、以前は HTTPS をサポートしていなかった Web サーバーと API ゲートウェイの構成の変更があります。 サポートするためにインフラストラクチャ (およびアーキテクチャ) に大幅な変更が必要になる場合があります。 さらに、証明書の有効期限の監視や証明書の交換など、運用上の変更も行う必要があります。

Secure Everything の時代における拡張は、容量の問題だけではなく、運用能力の問題でもあります。 安全なアプリ インフラストラクチャのサポートによる運用上の影響は軽微ではありません。 単なるチェックボックスや新しい構成ファイルではありません。

1. プロセスの変更

「DevOps を実行している」場合 (または実行していない場合でも)、デプロイメント パイプライン プロセスを調べて、HTTPS をサポートするために必要なコンポーネントが含まれていることを確認する必要があります。 つまり、キー、証明書、および構成をプロセスに含める必要があります。

2. 経営陣の変更

証明書の有効期限が切れます。 そして、もし彼らがそうするなら、それは「悪いこと」です。 運用部門は、証明書の有効期限がいつ切れるかを把握し、それらの証明書を更新して展開するためのプロセスが確立されていることを確認する必要があります (基本的には、GOTO #1 - プロセスの変更)。

3. 容量の変更

暗号化と復号化は、計算コストの点では安価ではありません。 以前ほど貪欲ではないとしても、安全な接続は安全でない接続よりも多くのリソースを消費します。 ユーザー数が非常に少ないアプリでは、目立った違いが見られない可能性があります。 しかし、（同時に）頻繁に使用されるものについては、スケールアウトできる容量を調べる必要があります。 サーバー（仮想または物理）だけでなく、インフラストラクチャも同様です。 これには、API ゲートウェイ (または API ゲートウェイのように動作するデバイス/システム) と、場合によってはサービス レジストリ (すでにコンテナーとマイクロサービスを使用している場合) が含まれます。

4. アーキテクチャの変更

エンドツーエンドの安全な接続は、ユーザーとアプリ間のすべてのセキュリティ サービスを妨害し、マルウェアや悪意のあるコードが機密データにアクセスできるアプリやサービスに到達するのを防ぐのに実質的に役に立たなくします。 安全な接続を傍受して検査する機能（受信時（リクエスト）と送信時（レスポンス）の両方）は、セキュリティ戦略を成功させるための重要な要素です。 侵入や感染を防止する役割を果たすために必要な可視性を重要なセキュリティ インフラストラクチャが継続的に確保できるようにするには、アーキテクチャの変更が必要になる場合があります。

安全な接続がコア ネットワークによって管理される 2 層アーキテクチャにより、証明書とキーがアプリ インフラストラクチャ全体に広がることに伴う運用上の問題を大幅に軽減できます。 これは、セキュアなプロキシによって、セキュアな接続をコア ネットワークで終了できるためです。 バックエンド アプリとの通信は、必要に応じてプレーンテキストのままにすることも、エンドツーエンドの安全な通信を維持するために再暗号化することもできます。 暗号化されていないデータは、セキュリティ ソリューション (IDS/IPS など) にミラーリングしてさらに検査できるため、既存のインフラストラクチャへの投資を維持できます。 つまり、証明書とキーを展開、管理、監視する中央の場所が 1 つ必要になります。 また、NS データ パスに戦略的なポイントを提供し、モバイル <—> アプリの通信に干渉することなく傍受と検査を行うことができます。

2層

いずれにせよ、アプリ (モバイルやその他のアプリ) に対する Secure Everything アプローチの規模への影響は、コンピューティング リソースの問題だけではなく、運用上の問題でもあります。 Apple がこれらの変化を推進しているのは確かだが、唯一の推進力ではない。 HTTP/2 の SSL/TLS 要件が公式標準から削除されたにもかかわらず、Web ブラウザー コミュニティは SSL/TLS 経由の HTTP/2のみをサポートすることに注意してください。 つまり、Web が HTTP/1x から HTTP/2 に移行するにつれて、Secure Everything は範囲を拡大し続けることになります。

アプリとユーザー間のあらゆる種類の暗号化されていない通信（法令または機能による）を排除するというこの継続的な取り組みにより、一部の組織ではプロセスと製品の大幅な変更が必要になります。