6月に開催されたAppleのWWDC（World Wide Developer Conference）で、モバイル業界の巨人である同社は、次のように発表しました。2017年1月1日以降、App StoreのすべてのアプリでApp Transport Security（ATS）を使用しなければなりません（ネットワーク技術者向けに補足すると、これはRFCで定義される「MUST」の意味です）。
要するに、アプリにHTTPではなくHTTPSの使用を義務付けるものです。
つまり、対応に残された期間はわずか数か月であり、その間に以下を行う必要があります。
- モバイルアプリを更新する
当然のことに思えるでしょう。何しろ、iOSのモバイルアプリにはHTTPSの使用が必須なのですから。まずはこれが必要です。 - バックエンドでHTTPSをサポートする
これはそれほど明白ではないかもしれませんが、HTTPSの目的は通信を保護することであり、少なくとも2者が関与することを意味します。モバイルアプリの場合、オンプレミスまたはクラウドにある何らかのエンドポイント（アプリ、サービス、APIゲートウェイ）が通信相手となります。このエンドポイントもHTTPSをサポートする必要があります。
2つ目の要件は、単にスイッチを入れれば済むものではないため、1つ目よりも技術面と運用面で複雑です。証明書と鍵の管理や配布、アップグレードに加え、これまでHTTPSに対応していなかったWebサーバーやAPIゲートウェイの設定変更も必要です。対応するには、インフラストラクチャ（およびアーキテクチャ）の大幅な変更が必要になる場合もあります。さらに、証明書の有効期限を監視して更新するなど、運用面の変更も必要です。
あらゆるもののセキュリティ確保が求められる時代において、スケーリングは単なるキャパシティの問題ではなく、運用能力も問われます。セキュアなアプリインフラストラクチャを支えるための運用上の負担は、決して小さくありません。チェックボックスをオンにしたり、新しい構成ファイルを用意したりするだけでは済まないのです。
1. プロセスの変更
「DevOpsを実践している」場合（実践していない場合も同様）、デプロイパイプラインのプロセスを見直し、HTTPSをサポートするために必要なコンポーネントが含まれていることを確認する必要があります。つまり、鍵、証明書、設定をプロセスに含める必要があります。
2. 管理上の変更
証明書には有効期限があります。そして、期限切れは「Bad Thing™」です。運用部門は証明書の有効期限を把握し、更新してデプロイするためのプロセスを整備する必要があります（つまり、基本的には「GOTO #1 – Process Change」です）。
3. キャパシティの変更
暗号化と復号には、相応のコンピューティングリソースが必要です。以前ほど多くのリソースを必要としなくなったとはいえ、セキュアな接続は依然として、セキュアでない接続よりも多くのリソースを消費します。ユーザーがごく少ないアプリでは、目立った違いが見られない場合もあります。しかし、同時に多くのユーザーが利用するアプリでは、スケールアウトに利用できるキャパシティを確認する必要があります。対象はサーバー（仮想または物理）だけでなく、インフラストラクチャも含まれます。具体的には、APIゲートウェイ（またはAPIゲートウェイとして機能するデバイスやシステム）に加え、すでにコンテナやマイクロサービスを使用している場合は、サービスレジストリも対象となる可能性があります。
4. アーキテクチャの変更
エンドツーエンドのセキュアな接続は、ユーザーとアプリの間にあるすべてのセキュリティサービスの機能を妨げ、機密データにアクセスできるアプリやサービスへのマルウェアや悪意のあるコードの到達を防ぐうえで、ほとんど役に立たなくなる可能性があります。セキュアな接続をインターセプトし、受信時（リクエスト）と送信時（レスポンス）の両方で検査できることは、効果的なセキュリティ戦略の重要な要素です。重要なセキュリティインフラが、侵害や感染を防ぐ役割を果たすために必要な可視性を引き続き確保できるよう、アーキテクチャの変更が必要になる場合があります。
セキュア接続をコアネットワークで管理する2層アーキテクチャにより、アプリインフラストラクチャ全体に証明書と鍵が分散することで生じる運用上の負担を大幅に軽減できます。これは、セキュアプロキシを使用してコアネットワークでセキュア接続を終端できるためです。バックエンドアプリとの通信は、必要に応じて平文のまま継続することも、再暗号化してエンドツーエンドのセキュア通信を維持することもできます。暗号化されていないデータをセキュリティソリューション（IDS/IPSなど）にミラーリングして詳細に検査できるため、既存インフラストラクチャへの投資を活用し続けられます。つまり、証明書と鍵の導入、管理、監視を1か所に集約できます。また、N-Sデータパス上に、モバイル <—> アプリ間の通信を妨げることなく傍受と検査を行える戦略的なポイントを確保できます。
いずれにしても、アプリ（モバイルを含む）に「Secure Everything」アプローチを適用すると、規模の面でコンピューティングリソースだけでなく、運用にも影響が及びます。Appleがこうした変化を促す大きな要因であることは確かですが、それだけではありません。HTTP/2の正式な標準からSSL/TLS要件が削除されたにもかかわらず、WebブラウザコミュニティはSSL/TLS経由のHTTP/2のみをサポートする点に留意してください。つまり、WebでHTTP/1.xからHTTP/2への移行が進むにつれて、「Secure Everything」の適用範囲は今後も拡大していきます。
規制や機能によって、アプリとユーザー間のあらゆる暗号化されていない通信を排除する動きが続く中、一部の組織では、製品だけでなくプロセスにも大幅な変更が必要になります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。