コーダーがセキュリティ・インフラストラクチャを征服するコードシリーズ:トランスポート層保護が不十分

組織内でセキュアなコードとしてのインフラストラクチャ (IaC) の導入を開始するために実行できる手順について詳しく知りたい開発者にとって、このサイトはまさにうってつけの場所です。これは IaC シリーズの次の章で、IaC セキュリティのベストプラクティスのレベルアップを目的としています。

始める前に、前回のチャレンジはどうでしたか？安全でない暗号をマスターしたことがあるなら、詳細を掘り下げる前に、トランスポート層保護が不十分な場合の対処法を見てみましょう。

詳細を学び、満点を獲得したいですか？続きを読む:

前回の記事では、アプリケーションやプログラムに保存されている重要なデータや個人データを保護するための安全な暗号化の重要性について説明しました。強固な暗号化を採用していれば、最後の防衛線として完璧に機能します。攻撃者がそのデータを盗むことができたとしても、そのデータが強力に暗号化されていれば、それらのファイル内にロックされている情報は保護されます。

ただし、保管中のデータを保護することは、完全なデータ防御の一部にすぎません。有効なユーザーが保護されたデータにアクセスする必要がある場合はいつでも、そのユーザーにそのデータを送信する必要があります。ときには、全体的なワークロードの一部として、アプリケーションが他のプログラムとデータを共有することもあります。トランスポート層が保護されていない限り、外部からの覗き見や不正な内部閲覧の両方に対して脆弱になります。そのため、トランスポート層の保護が不十分だと、深刻な問題が発生する可能性があります。

よくある問題です。OWASP のセキュリティ組織は、以下の内容に関するページもすべて管理しています。 トランスポート層保護が不十分。

トランスポート層の保護が不十分であるのはなぜ危険なのですか？

トランスポート層を十分に保護しないと、熟練したハッカーが中間者攻撃などの手法を使用して、ユーザーとアプリケーションの間を流れる情報を傍受するのは比較的簡単です。この種のスヌーピングで最も危険な側面は、ネットワークや制御の及ばない場所で発生するため、内部のサイバーセキュリティプラットフォームやスキャンからはほとんど見えないことです。

たとえば、Nginx サービスをデプロイしている Docker 環境では、次のようになります。

サービス:
nginx:
イメージ:ローカルホスト:5000/scw_nginx
ビルド:。/nginx
秘密:
-nginx_cert
-nginx_key
ボリューム:
-タイプ:バインド
ソース:。/nginx/nginx.conf
ターゲット:/etc/nginx/nginx.conf
読み取り専用:はい
ポート:
-80:8443
ネットワーク:
-フロントエンド
デプロイ:
再起動ポリシー:*デフォルト再起動ポリシー
リソース:*デフォルト-リソースポリシー

Nginxのサービス構成では接続を暗号化または保護しないため、リンクを介して交換されるすべての情報は、さまざまな攻撃やスヌーピングに対して脆弱になります。

サーバー {
サーバー名 scw-dev-blog.org;
8443を聞いてください。
SSL プロトコル TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
SSL_prefer_server_ciphers オン;
SSL_certificate /run/secrets/nginx_cert;
SSL_certificate_key /run/secrets/nginx_key;
アクセスログ /dev/stdout;
エラーログ /dev/stderr;
場所/{
proxy_pass http://wordpress:8080;
プロキシセットヘッダーホスト $http_host;
プロキシセットヘッダー X-Forwarded-Host $http_host;
プロキシセットヘッダー X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
プロキシセットヘッダー X-Forwarded-Proto $Scheme;
}
}

多くの場合、誰かがトランスポート層を覗き見している最初の兆候は、盗まれたユーザーパスワードが大量にその後の攻撃で使用された場合です。顧客情報、財務記録、重要な企業秘密などの他のデータが、安全でないトランスポート層を介して盗まれても、自分が侵害されたことに気付かない場合もあります。

保護が必要なのは、ユーザーとアプリケーション間のトランスポート層だけではありません。バックエンドでは、多くのアプリケーションが相互に通信し、ワークフローチェーンのさらに奥にあるサーバーとも通信します。これらの内部通信は一般に外部からの覗き見に対して脆弱ではありませんが、ネットワークへのアクセスは許可されているが、高度に保護された特定の情報や機密情報の閲覧は許可されていないユーザーにデータが漏洩する可能性があります。

完全なデータ保護のためのトランスポート層の適切な保護

トランスポート層の保護は、アプリケーションの作成中に行うのが最適です。このプロセスは、安全なバックエンド・インフラストラクチャーの構築から始まります。ウェブサイトでは、すべてを HTTPS を使用して行う必要があります。HTTP と HTTPS のインフラストラクチャーを混在させないでください。さらに、セキュリティで保護されていない HTTP リクエストを HTTPS インフラストラクチャに自動的にルーティングするようにサイトを設定する必要もあります。

上の例では、トランスポート層を保護する適切な方法は次のようになります。

サーバー {
サーバー名 scw-dev-blog.org;
8443 SSLを聞いてください。
SSL プロトコル TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
SSL_prefer_server_ciphers オン;
SSL_certificate /run/secrets/nginx_cert;
SSL_certificate_key /run/secrets/nginx_key;
アクセスログ /dev/stdout;
エラーログ /dev/stderr;
場所/{
proxy_pass http://wordpress:8080;
プロキシセットヘッダーホスト $http_host;
プロキシセットヘッダー X-Forwarded-Host $http_host;
プロキシセットヘッダー X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
プロキシセットヘッダー X-Forwarded-Proto $Scheme;
}
}

この例では、Nginx サービスとのすべての接続は強力に暗号化されています。Nginx 設定のサーバーセクションには以下しか含まれていません。 リッスン 8443 SSLによる接続保護を強制するためです。

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

また、保管中のデータとトランスポート層の両方が十分に保護されるまで、アプリケーションの保護は完全には完了しないということを常に念頭に置いてください。そうすれば、内部と権限のある外部ユーザーに転送される際の両方で、データをエンドツーエンドで完全に保護できます。
をチェックしてください セキュア・コード・ウォリアー この脆弱性や、他のセキュリティ上の欠陥による被害から組織や顧客を保護する方法についての詳細な情報については、ブログページをご覧ください。また、次のこともできます。 デモを試す Secure Code Warriorトレーニングプラットフォームで、すべてのサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。