ログファイルの機密データを保護するためにどのような戦略を採用できますか？

高度に規制された環境での作業データは、感度に応じてさまざまな方法で分類されます。場合によっては、これは法的に強制され、別の扱いが必要になります。

データ分類ポリシーの例は次のとおりです。

• パスワード、秘密鍵、SAMLトークン、クレジットカード番号などの非常に制限されたデータ。
• ユーザー名やお客様IDなどの制限されたデータ。
• 無制限のデータ、ほとんど何でも。

この分類には特定の義務が伴います。

• 厳しく制限されているデータは、いかなる状況でもログファイルで利用可能にしてはなりません。

• 特定の条件下では、制限されたデータがログファイルで利用可能になる可能性があります。たとえば、サービスでインシデントが発生した場合、オンコールエンジニアはBreak-Glass手順を実行して、このデータにアクセスして問題を診断できます。次に、Break-Glass手順により、レビュー、監査、および場合によってはそのエンジニアからの一時的な特権の取り消しがトリガーされます。

これを達成するためにどのような戦略を採用することができますか？特に、この問題に直接的な回答を提供しない、幅広いロギング、モニタリング、および計測ツールが市場に出回っていることを考えると？

たとえば、SplunkとAppDynamicsのどちらにも、公開されているテレメトリの条件に応じて異なるアクセス制御を課すことができます。つまり、マスクするフィルターを作成できます<customerId>NNNNNNNNNNNN</customerId>。ただし、これらのツールはどちらも、クレジットカード番号を自動的に識別して自動的にマスクする機能を提供しません。

注：これはDevOpsに関連していると思います。これは、従来の階層型サポートモデルでは、比較的少数のグループがデータにアクセスして手動でフィルタリングできるため、オペレーティングチームの責任を開発チームに委譲することにより、このデータが遠くにさらされる可能性があるためです。より広い聴衆。

ソリューションは、データ保護を保証する幅広いアプローチに帰着すると思います。

• データの分類：最も効率的な技術戦略は、作成時点のデータを厳密に分類することです。基本的に、開発者はすべてのログ情報にカテゴリが割り当てられるようにする責任があります。たとえば、Splunkメタデータを使用して分類を行うことができます。Splunkメタデータを使用すると、データの分類に基づいてログエントリをさまざまなバケットに送信できます。

• イベントのパーティショニング：多くの場合、機密情報と一緒に機密情報をログに記録したいという要望があります。たとえば、新しいユーザーがサインアップする場合、ログに記録できます。

  • お客様ID（制限付き）
  • 顧客タイプ（制限付き）
  • 取得ソース（無制限）
  • 相関ID（無制限）

  二つの部分、含むものには、この1「イベント」を分割することが可能である制限された情報と第1含む無制限の情報を。これは、フィルタリングルールが異なるバケットに送信されるようにすることで、最初のポイントと一致します。

• データマスキング：特定の状況では、ソースでデータを分類できない場合があります。私の経験では、ロギングソリューションでは、マスキングルールで機密データをXで除外できます。リンクされた例では、sedコマンドを使用して、特定のソースからのすべてのデータに正規表現を適用します。制限されたデータがマスクされると、イベントは制限なしと見なされます。相関IDなどのイベントにとって重要な情報が、機密データの照合に使用される正規表現と一致しないように、ルールに注意を払う必要があります。

• イベントのフィルタリング：最後の手段として、特定のタイプまたはソースのすべてのイベントを、分類またはマスクできない機密データが含まれている場合は、別のバケットにフィルタリングする必要がある場合があります。この場合、制限付きバケット内の情報には、Break-Glassメカニズムを介してのみアクセスでき、インシデントの規定に基づくアクセス制御をバイパスできます。

これらの各ソリューションでは、亀裂が何も抜けないことを確認するためのテストが鍵となります。ロギングとイベント管理は、ソリューションに適用される同じレベルの開発の厳​​密さを備えたファーストクラスの非機能要件であると見なされなければなりません。

それは、私が想定した「ログファイル」の意味によって異なります。システムが正常に動作していることを確認するために使用するテレメトリデータを意味する場合、「機密フィールドをログに記録しない」と言います。トランザクション率の高低、依存サービスへの応答時間などを警告するために、このような情報は必要ありません。

請求または監査の目的でデータを意味する場合は、書き込み専用パイプラインを確立して、データは書き込まれるが、ライターが読み取ることができないようにすることをお勧めします。次に、請求および監査パイプラインが開始され、個々のレコードを見た人を監査するためのコントロールがあります。

最終的にセキュリティは、独自の安全なログファイルなどを備えた文書化されたプロセスに帰着します。すべてのデータは後で読み取れるように書き込まれるため、ある時点で誰かまたは何らかのプロセスを信頼する必要があります。