セキュリティを制する者は、Infrastructure as Codeシリーズを制す。トランスポート・レイヤー・プロテクションの不備

セキュアなIaC（Infrastructure as Code）を組織に導入するための手順を知りたい開発者の方は、ぜひ参考にしてみてください。本章は、IaCシリーズの次の章で、IaCセキュリティのベスト・プラクティスのレベルアップを目的としています。

始める前に、前回の課題はどうだったでしょうか？安全でない暗号をマスターした人は、詳細を見る前に、不十分なトランスポート層保護をどうするか見てみましょう。

もっと勉強して満点を目指しませんか？読んでみてください。

前回の記事では、アプリケーションやプログラムに保存されている重要なデータや個人情報を保護するために、安全な暗号化を行うことの重要性についてお話ししました。強力な暗号化があれば、それは完璧な最終防衛ラインとして機能します。たとえ攻撃者がデータを盗むことができたとしても、強力に暗号化されていれば、そのファイルの中に閉じ込められた情報は守られます。

しかし、静止状態のデータを保護することは、完全なデータ防衛の一部分に過ぎません。有効なユーザーが保護されたデータにアクセスする必要がある場合は、データを送信する必要があります。また、アプリケーションは、全体的なワークロードの一環として、他のプログラムとデータを共有することもあります。トランスポート層が保護されていないと、外部からの盗み見や内部からの不正な閲覧に対して脆弱になります。このように、トランスポート層の保護が不十分であると、深刻な問題が発生します。

これは一般的な問題です。OWASPセキュリティ組織は、不十分なトランスポート層保護に関するページを設けています。

なぜトランスポートレイヤーの保護が不十分だと危険なのか？

トランスポート層を十分に保護していない場合、熟練したハッカーは、中間者攻撃などの手法を用いて、ユーザとアプリケーションの間を流れる情報を比較的容易に傍受することができます。

例えば、Docker環境でNginxサービスをデプロイした場合の例です。

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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。