コーダーが征服するセキュリティ：Infrastructure as Codeシリーズ：不十分なトランスポート層保護

組織内でInfrastructure as Code（IaC）のセキュアなデプロイを始めたいと考えている開発者の方は、ぜひこの記事をご覧ください。本稿は、IaCセキュリティのベストプラクティスを習得するための「IaCシリーズ」の次章となります。

本題に入る前に、前回の課題はいかがでしたか？「安全でない暗号化」をマスターできた方は、詳細を掘り下げる前に「不十分なトランスポート層の保護」に挑戦してみましょう。

さらに詳しく学び、完璧なスコアを目指したい方は、ぜひ読み進めてください。

前回の記事では、アプリケーションやプログラムが保存する重要データや個人情報を保護するために、安全な暗号化が不可欠であることを解説しました。強力な暗号化は、最後の防衛線として機能します。たとえ攻撃者にデータが盗まれたとしても、強力に暗号化されていれば、ファイル内の情報は保護されます。

しかし、保存データの保護は、データ防御のほんの一部に過ぎません。有効なユーザーが保護されたデータにアクセスする必要があるときは、そのデータをユーザーに送信しなければなりません。また、アプリケーションが全体的なワークロードの一環として他のプログラムとデータを共有することもあります。トランスポート層が保護されていない場合、外部からの盗聴や、権限のない内部ユーザーによる閲覧に対して脆弱になります。そのため、トランスポート層の保護が不十分であることは、深刻な問題を引き起こす可能性があります。

これはよくある問題です。セキュリティ組織のOWASPも、不十分なトランスポート層の保護（insufficient transport layer protection）に関する詳細なページを公開しています。

なぜトランスポート層の保護が不十分だと危険なのでしょうか？

トランスポート層の保護が不十分な場合、熟練したハッカーが中間者攻撃（MITM攻撃）などの手法を用いて、ユーザーとアプリケーション間を流れる情報を傍受することは比較的容易です。この種の盗聴の最も危険な点は、ネットワークの外側で行われるため、内部のサイバーセキュリティプラットフォームやスキャンからはほぼ完全に不可視であることです。

例えば、NginxサービスをデプロイするDocker環境の場合：

services:
 nginx:
   image: localhost:5000/scw_nginx
   build: ./nginx
   secrets:
     - nginx_cert
     - nginx_key
   volumes:
     - type: bind
       source: ./nginx/nginx.conf
       target: /etc/nginx/nginx.conf
       read_only: yes
   ports:
     - 80:8443
   networks:
     - frontend
   deploy:
     restart_policy: *default-restart_policy
     resources: *default-resources_policy

このNginxサービスの設定では接続が暗号化・保護されないため、リンクを通じてやり取りされるすべての情報が、さまざまな攻撃や盗聴に対して脆弱になります。

server {
       server_name scw-dev-blog.org;
      listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

多くの場合、トランスポート層が盗聴されている最初の兆候は、盗まれた大量のユーザーパスワードがその後の攻撃で使用されることです。顧客情報、財務記録、重要な企業秘密などのデータが安全でないトランスポート層を通じて盗まれた場合、侵害されたことにすら気づかない可能性があります。

保護が必要なのは、ユーザーとアプリケーション間のトランスポート層だけではありません。バックエンドでは、多くのアプリケーションが相互に、あるいはワークフローチェーンの先にあるサーバーと通信しています。こうした内部通信は通常、外部からの盗聴にはさらされませんが、ネットワークへのアクセス権はあるものの、特定の高度に保護された機密情報へのアクセス権を持たないユーザーに対してデータが露出する可能性があります。

完全なデータ保護のためのトランスポート層の適切なセキュリティ対策

トランスポート層の保護は、アプリケーションの作成段階で行うのが最善です。このプロセスは、セキュアなバックエンドインフラを構築することから始まります。Webサイトの場合、すべてHTTPSを使用する必要があります。HTTPとHTTPSのインフラを混在させてはいけません。また、安全でないHTTPリクエストをHTTPSインフラへ自動的にルーティングするようにサイトを設定すべきです。

上記の例において、トランスポート層を保護する適切な方法は以下の通りです。

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

この例では、Nginxサービスとのすべての接続が強力に暗号化されています。Nginx設定のサーバーセクションには、listen 8443 ssl のみが含まれており、SSLを強制して接続を保護しています。

内部の脅威からデータを保護するため、開発者はTLS 1.2のような強力なトランスポート層暗号化プロトコルを採用すべきです。TLS 1.2または同等のプロトコルを導入したら、SSL v2のような脆弱なプロトコルはインフラストラクチャから完全に削除し、二度と使用されないように自動的にブロックする必要があります。

アプリケーションのセキュリティ対策は、保存データとトランスポート層の両方が十分に保護されて初めて完了することを忘れないでください。これにより、内部データおよび許可された外部ユーザーへ送信されるデータの両方に対して、完全なエンドツーエンドの保護を保証できます。
この脆弱性に関する詳細や、その他のセキュリティ上の欠陥から組織や顧客を守る方法については、Secure Code Warriorのブログページをご覧ください。また、デモを試して、Secure Code Warriorトレーニングプラットフォームでサイバーセキュリティスキルを常に最新の状態に保つことも可能です。