セキュリティではなくレイテンシーの削減

コンテンツ・セキュリティ・ポリシー（CSP）は、クロスサイト・スクリプティング（XSS）やデータ・インジェクション攻撃など、さまざまな種類の攻撃からWebサイトやWebアプリケーションを保護するために、Webブラウザに実装されているセキュリティ機能です。CSP は、Web ページ上でロードまたは実行される可能性のあるさまざまな種類のコンテンツのソースを制御および制限します。これらのタイプのコンテンツには以下が含まれます：

• スクリプト
• スタイルシート
• イメージ

この投稿では、まずCSPがどのように機能するかを見ていこう。より効果的でダイナミックなCSPの利用には、サーバーで行われる必要がある計算も含まれることがわかるだろう。しかし、その計算をエッジに移すことで、待ち時間を短縮し、最適なエンドユーザー・エクスペリエンスを確保することができる。また、このエッジ・コンピューティング・ソリューションがどのように機能するかも探ります。

飛び込む準備はできていますか？CSPの仕組みを理解することから始めましょう。

CSPの仕組み

CSP は通常、サーバ側に Content-Security-Policy ヘッダーをHTTPレスポンスに追加します。このヘッダーは、ウェブサーバーがウェブページをリクエストしたユーザーに送信します。このヘッダーは、ブラウザがページ上のコンテンツを読み込んで実行する際に従うべきルールを指定します。

設定例 Content-Security-Policy ヘッダー

例えば、Node.js でExpressを使用しているとします。 このようにCSPヘッダを設定します：

const express = require('express'); const app = express(); app.get('/', (req, res) => {   res.set('Content-Security-Policy', 'directive1 value1; directive2 value2; ...');   res.status(200).send('hello world'); });

FlaskでPython 、コードは次のようになる：

app = Flask(__name__) @app.route('/hello', methods=['GET']) def hello_world():     response = make_response('hello world')     response.headers['Content-Security-Policy'] = 'directive1 value1; directive2 value2; ...'     return response

ディレクティブを使う

各 CSP ヘッダは複数のディレクティブを持つことができ、各ディレクティブは提供される設定のタイプに適した値を持つことができます。これらのディレクティブは、さまざまなタイプのリソースのセキュリティ・ルールを定義します。例えば script-src ディレクティブは、 スタイルシートに許可されるソースを指定します。

以下のCSPヘッダを考えてみよう：

Content-Security-Policy: default-src 'self'; script-src 'self' https://static.example.com; style-src 'self' 'unsafe-inline';

上のヘッダには3つのディレクティブがあり、それぞれに値が付随している。

• のです。 default-src ディレクティブを 'self'デフォルトでは、すべてのコンテンツはページ自身と同じオリジンからロードされるべきであることを指定します。
• のです。 script-src ディレクティブは、スクリプトが同じオリジン ('self')と指定された外部ソース(https://static.example.com).
• のです。 style-src ディレクティブは、スタイルシートが同じオリジンから読み込まれるようにし、インラインスタイルも可能にします。

利用可能なディレクティブのリストは、実際にはかなり網羅的です。ここにあります。ディレクティブは以下の通りです：

• font-src:を使用してロードされたフォントのソース @font-face
• frame-src:などの要素にロードされたネストされたブラウジング・コンテキストのソース。 <frame> と <iframe>
• img-src:画像とファビコンのソース

CSPをHTMLに結びつける

CSPヘッダがサーバに設定されると、ブラウザはWebページのリソースをロードする際にこれらのルールを適用します。

HTML ソースでは、開発者は（スクリプトやスタイルシートなどの）要素をインラインで追加したり、（同じオリジンまたは他の場所からの）リソースを参照したりできます。ブラウザは次にCSPヘッダをチェックし、これらのリソースが定義されたルールに準拠していることを確認します。リソースがCSPによって許可されていない場合、ブラウザはそのインクルードと実行をブロックします。

すべてのリクエストでユニーク

CSP ヘッダはどのように定義されるため、通常、特定の Web ページに対するすべてのリクエストで一貫しています。1 つのページの各リクエストの詳細とディレクティブは、そのページの後続の各リクエストでも同じになります。

そこで興味深い疑問が浮かんだ：動的なインライン・スクリプトやスタイルをどう扱うか？すべてのインライン・スクリプトやスタイルを含めることを許可せずに、特定のインライン・スクリプトやスタイルの実行を許可したい場合があります。

このシナリオでは、nonce 値またはハッシュを導入して、スクリプトまたはスタイルのソースが CSP に明示的にリストされていなくても、CSP ヘッダで指定された nonce 値またはハッシュ値に一致する限り、実行できるようにすることができます。

これらのnonce値やハッシュは、リクエストごとに変更される可能性がある。そのため、これらはサーバー上で生成され、管理される必要がある。しかし、これらのnonceやハッシュをサーバーで実行する必要があるからといって、必ずしもサイトのメインサーバーで実行する必要はない。そこでエッジ・コンピューティングの出番となる。

エッジコンピューティングとは何か？

エッジ・コンピューティングとは、基本的に、エンドユーザーに地理的に近いネットワークの外縁で計算を実行するように設定できるという概念です。基本的には分散コンピューティングの一種であり、インターネット上であってもリアルタイムの計算速度に近づけ、ネットワークの待ち時間を短縮することが可能です。

エッジ・コンピューティングを使えば、CSPヘッダーのnoncesとハッシュをエンドユーザーの近くで生成し、エンドユーザーがサイトのセキュリティを確保するまでの時間を短縮することができる。

エッジコンピューティングがCSPにどのように役立つか

CSPがサイトを遅くする主な理由の1つは、ヘッダ内のnonceがキャッシュ・ミスを引き起こす可能性があり、顧客のブラウザが最も新鮮なヘッダを適切に生成するために、サイトのサーバにわざわざアクセスする必要があることです。これに対処するには、エッジ・インスタンスに動的CSP nonceジェネレータを実装します。これによって、セキュリティを維持しつつ、キャッシュがまだ有用であることを保証する方法が提供される。

このアプローチの利点は以下の通りである：

• 待ち時間の短縮：エッジコンピュートインスタンスはnonceを生成し、リクエストに挿入する。nonceが挿入されたリクエストは、キャッシュにトラバースし続けるので、リクエストが行われるたびにオリジンサーバーに新しいレスポンスをフェッチする必要がなくなる。
• 分散セキュリティ：エッジ計算を使用することは、顧客がシステムのプライマリ・サーバやアプリケーション・コードとやり取りする前に、セキュリティの追加レイヤを持つことを意味します。たとえアプリケーションに脆弱性があったとしても、CSP nonce を計算するエッジ計算によってセキュリティのレイヤーが追加され、潜在的な問題を軽減することができます。
• メンテナンスの容易さ：エッジでCSPヘッダーの動的Nonceをサーバーレス・アプローチで管理すれば、メンテナンス作業が簡素化される。特に、アプリケーション・コードを変更することなくCSPポリシーを管理できる。また、特別なコードのデプロイを行うことなく、中央制御システムからこの種の変更を管理することも通常可能だ。また、これらのエッジ計算関数は、複数の独立したアプリケーションで使用することができるため、各アプリケーションを担当する特定のチームからの懸念を分離し、セキュリティ専門家が正しいノンス生成が行われていることを確認することができます。

結論　

エッジ コンピューティングの活用についてご興味がおありですか？それなら、アカマイの注目製品をご覧ください。特にEdgeWorkersは、お客様のネットワークのエッジにサーバーを配置する複雑な方法を考えずに、この記事で説明したことをまさに実現できるサーバーレス体験を提供します。

今すぐ無料トライアルにお申し込みください！キャッシュ・スキームを台無しにしない、より良いCSPヘッダーでサイトの安全性を確保しましょう！