Apache Nginx
某フリマサービスのシステム変更の際に、CDNの仕様把握を誤った為に、会員情報をCDNにキャッシュしてしまい、購入履歴、住所やクレカ情報の一部といった会員の個人情報を漏えいしてしまった事故が先日ありました。

そこで今回はNginxの基本的なキャッシュコントロールに関するディレクティブをおさらいする記事にします。

 

まずはシンプルに。

 

判定

Nginx キャッシュ 無効化

 

304の判定とEtagも判定させたくありません。Etagはアンテナサイトなどと連携している場合には不具合になる場合もあります。

  • sendfile
    OSのキャッシュ。
  • if_modified_since
    更新通知を判定します。304の場合はデータを取りにいきません。
  • Etag
    ブラウザキャッシュの管理番号ようなもの、サーバ側で更新されたら値が変わるので、ブラウザはデータを取りにいきます。同じ値であれば更新されていないものとしてブラウザのキャッシュを利用するため高速な処理になります

上記を踏まえて変更

 

判定

いいですね。

 

 

no-cacheディレクトリだけキャッシュしない。

 

キャッシュは便利だけれど、怖い

Nginxのキャッシュ機構を採用する場合は、絶対に管理画面系をキャッシュしてはいけませんし、その場合は少しコンフィグが複雑になります。利用時は必要な部分だけキャッシュを添えて、安全に利用しないといけない。

 

また、冒頭の某フリマサービスのケースに戻りますが、新たなCDNをうまく使うには

privateになっていないとページをキャッシュしてしまうという仕様だった模様です。なにこれ怖い!

 

技術的な失敗例を教えて貰えるのはとても有難い(ㆁᴗㆁ✿)

トラブルや失敗例に学ぶことって勉強になります。頭の中に失敗例のインデックスを作っておくと、自身が管理するシステムの障害が起こった時に、障害の予測が速くなりますし、失敗例に陥るアンチパターンなシステムを組まずに済みます。

 

今回のケースの教訓として

外部サービスを変更する場合は、そのサービスの仕様の細かい把握が必要であること、検証を重ねて行なわないといけない。言うのは簡単ですが。

お疲れ様です。

金広 優 (エンジニア)
この記事を書いた人:金広 優 (エンジニア)

システムガーディアン爆弾処理班。アクセス負荷対策やNginxへの移行案件が多いこの頃。IBM SoftLayerやAWSなどクラウド案件も多くなってきました。