You push a release late at night, glance at your alerts, and notice a credential that never should’ve left a private repo. Maybe it was a database password. Maybe it was a cloud access key with broader permissions than anyone intended. Either way, the problem isn’t just that someone could log in. The problem is that database security continues to be treated like a login problem when it’s really a storage lifecycle problem.
That shows up everywhere in real systems. Teams enable encryption once and assume they’re done. They keep backups but never test restore. They create an admin service account for convenience and forget it exists. They lock down production, then leave staging full of copied customer data. If you’re building mobile or web apps, secure database storage has to cover all of it: the primary database, the replicas, the exports, the logs, the backups, and the keys that control the whole thing.
If you’re also working through solving auth for your next app, remember that authentication and storage security solve different failure modes. Auth decides who should get in. Storage security limits damage when someone does, or when data leaks through a path you didn’t expect. For teams shipping customer-facing apps, it’s also worth aligning storage decisions with adjacent controls like API security standards for app store compliance.
__CAPGO_KEEP_0__ 2020年には、64.2ゼタバイトのグローバルデータ生産が達成され、2025年までに180ゼタバイトに達する予想がありました。 __CAPGO_KEEP_0__ エッジデルタのデータストレージサマリーによると。
その規模では、安全なストレージはハード化タスクではなく、設計上の要件となります。
- コンテンツ
- 資格情報の乱用に対して防御が存続する必要がある
- 最も重要な脅威の3つのバケット
- 暗号化の実践的な実装パターン
- マスター キーとシークレットの管理をマスターする
- 耐障害のバックアップと復元戦略の設計
- セキュアなデータベースストレージのための開発者チェックリスト
- よくある質問
データベースセキュリティはパスワードだけではありません
パスワードはエントリポイントを保護しますが、資格情報が漏洩したり、スナップショットがコピーされたり、内部サービスが表現されていないテーブルを読み取ったりすると、データは保護されません。 したがって、安全なデータベースストレージには層が必要です。
古いメンタルモデルは単純でした: データベースをファイアウォールの背後で置き、強力なパスワードを要求し、外部者を遠ざけます。 しかし、このモデルはクラウドシステム、モバイルバックエンド、モダンCI/CDパイプラインで機能しません。 データはサービス間で移動します。 エンジニアは一時的なエクスポートを作成します。 分析ジョブはレコードを複製します。 バックアップシステムは異なるインフラストラクチャ上でコピーを保存します。 攻撃者はデータベースエンジンを破る必要はありません。 ただし、キーを盗んだり、API トークンを悪用したり、弱い制御を持つレプリカを発見したりすることができます。
静かなパスでセキュリティが失敗する
最も損害のあるストレージの失敗は最初は劇的なものではなく、普通のもののように見えます。
- 開発者にとっての便利さが生産性のリスクになる: 共有管理資格がスクリプトによって再利用される:
- 管理資格を回転すると展開が破壊されるため。 コピーされたデータセットが管理から逃げる:
- 生産レコードがステージングにクローンされるので、QAがバグを再現できる。 バックアップが弱点になる:
生産には強い制御が実施されているが、復元バケットまたはスナップショットポリシーが弱い。 If the only thing standing between an attacker and readable data is one credential, you don’t have secure storage. You have a single point of failure.
攻撃者が読み取れるデータと一つだけの資格情報だけが立ちはだかっている場合、安全なストレージを持っていません。 1 つの弱点しかありません。
防御は資格情報の悪用を生き延びなければなりません。 マイクロソフトのクラウドガイドラインでは、データのクラウドセキュリティベストプラクティスに基づいて、データの転送と保存の暗号化、最小限の特権アクセス制御、未承認の活動の監視を含むベースラインを推奨しています。実際のインシデントは、有効なアクセスを誤用したことから始まることがよくあります。
実践で機能するものは、面白くないもので、安定したものです。 データベースファイルを暗号化してください。 接続を暗号化してください。 サービスロールを分割してください。 できるだけ立ち往生した管理者アクセスを削除してください。 感度の高い操作をログしてください。 正常な使用とは異なるアクセスパターンにアラートを設定してください。 それらはすべて、実際の侵害を防ぐためには、面白くないものですが、実際の侵害を防ぎます。
実用的な方法で考えると、物理的な金庫と同じです。 金庫のドアは重要です。 そして、コンパートメントロック、カメラ映像、訪問者ロジン、どの箱を開けることができるかというポリシーも重要です。 安全なデータベースストレージは同じように機能します。 パスワードはただの前ドアだけです。
データベースの脅威モデルを理解する
脅威モデルを構築する前に、システムがどのように失敗するかをマップする必要があります。 データベースストレージの脅威モデルには、学術的なものは必要ありません。 それが、誰が敏感なデータに触れることができるか、どのように触れるか、そして成功した場合に何が起こるかを教えてくれる必要があります。
敏感データはほとんどが一つの整理された生産データベースに存在しません。現代のガイドラインでは、敏感情報がコピー、バックアップ、ログ、開発環境などに存在する可能性があるため、発生する失敗は主なデータベース外で発生することが多いことを強調しています。 Sentraによるクラウドデータセキュリティとポジチュアマネジメントの概要そのため、インシデント計画には、ベンダーエクスポージャーとコピーされたデータセットなどのシナリオを含める必要があります。これは、より広範な対応プレイブック、 第三者企業の侵害対応ベストプラクティス、が関連することになります。
ツールではなくアセットから始めましょう。
重要なものをリストする前に製品をリストしましょう。
ほとんどのアプリチームにとって、重要なアセットは簡単にわかります。
- 顧客レコード 例えばプロファイル、注文履歴、決済関連メタデータ、または健康関連コンテンツ。
- 認証材料 例えばパスワードハッシュ、セッションレコード、リフレッシュトークン、またはAPIシークレット。
- 運用データ such as audit logs, job queues, admin notes, and support exports.
- 復元資産 such as snapshots, logical dumps, point-in-time logs, and encryption keys.
最後のアイテムはチームが思っているよりも重要です。攻撃者がバックアップを削除したり、暗号化を解除するためのキーにアクセスしたりすると、復元ストーリーが崩壊します。
最も重要な脅威の 3 つのバケット
開発者と一緒に使用するシンプルなモデルは 3 つのバケットがあります。
外部の攻撃者
これは最初に考えるバケットです。SQL インジェクション、盗まれた API トークン、漏洩したクラウド認証情報、公開された管理パネル、脆弱な依存関係。共通のテーマは、データへのアクセスを得るために外部からパスを得ることです。
質問すること
- データベースをアプリケーションを通じて間接的にクエリできるか?
- 盗まれたサーバークレデンシャルが、必要なサービスよりも多くのサービスを読むことができるか?
- __CAPGO_KEEP_0__
内部リスク
データの漏洩は、悪意のある内部者や過度に権限のある従業員も含めます。サポートエンジニアがチケットを解決するためにデータをエクスポートする。契約者がローカルコピーを保持する。プラットフォーム管理者が生産行を読むことができるが、その役割には必要ない。
役割に基づくアクセス制御や監査トレイルが敏感な読み取りを明らかにすることで、分離された権限や役割に基づくアクセス制御が役に立ちます。
データの漏洩を防ぐには、誰が顧客レコードにアクセスしたか、いつアクセスしたか、どのようなアクセスが許可されたかを答えられない場合は、データベースの制御が弱いと言えます。
誤ってデータを公開する
このカテゴリは、迅速に動くチームで最も一般的なものです。ストレージバケットの誤構成。ライブデータでセedingされたステージング環境。トークンや個人情報を含むデバッグログ。トラブルシューティングのために低セキュリティ環境に復元されたバックアップ。
誤ってデータを公開することは、強力なストレージセキュリティがオペレーショナルである必要がある理由です。1 つの設定で解決するのではなく、データの分類、ガードレール、レビュー、定期的なクリーンアップで解決する必要があります。
セキュアなデータベースストレージの基本原則
侵害はほとんどの場合、1 つの大きな失敗から来ません。通常は、連続した普通のミスから来ます。バックアップが間違ったアカウントにコピーされる。サービスが必要以上の権限を取得する。古いキーが数か月間有効なままになる。古いキーが回転が遅れ続けていたためです。セキュアなデータベースストレージは、システムが変化するたびにその連鎖を複数の点で中断し続ける必要があります。
Iは、暗号化、認可、監査、最小化の4つの柱に仕事をグループ化します。バックアップと復元も重要ですが、独自の運用処理が必要です。復元されたデータは、誰がデータを読むことができるか、どのキーが復号できるかをテストしないと、データが新しい露出パスになる可能性があります。
盗難されたデータの価値を削減する
データが盗難された場合、暗号化は時間を稼ぎ、影響を軽減します。ディスクスナップショット、RAWバックアップファイル、または内部ネットワークからトラフィックを取得した場合、暗号化されたデータは、顧客レコードに変換するのが非常に難しくなります。
暗号化は、データベースファイル、スナップショット、バックアップアーティファクトを保護します。アプリケーションサーバー、プロキシ、データベースエンジン間の接続を保護するTLSは、データが移動している際に保護します。NISTは、SP 800-111と関連するデータ・アット・レストの推奨事項で、両方の制御を取り扱っています。 トレードオフは、運用上のものであり、理論上のものではありません。暗号化は、キー管理がデータパスから分離され、長期にわたって維持される場合にのみ役立ちます。エンベロープ暗号化は、ビルディングマスターキーとロックされたオフィスキーと同じように機能します。マスターキーを保護するキー管理サービスがあり、短期間のデータキーを使用して実際のレコードまたはファイルを暗号化します。設計は、ローテーション中の露出を制限し、すべてを一度に書き直すことなく、キー材料を削除または置き換えることを容易にします。.
__CAPGO_KEEP_0__
チームは、暗号化を有効にしただけで終わるとトラブルになることがあります。鍵の場所、鍵を使用できるユーザー、鍵のローテーションが予定されているか、古いバックアップが忘れられた鍵のバージョンに依存しているかを確認する必要があります。
アクセス制御は爆発半径を制限する
権限はアプリケーションの境界を遵守するべきであり、組織図ではありません。
チェックアウト API のデータベースロールは給与データを読むことができないようにし、バックグラウンドワーカーはスキーマ変更権限を持たないようにしてください。早い段階の移行の際に便利だったため、サポートツールは広範なテーブルへのアクセスではなく、フィルタされたビューまたは承認された手順を使用する必要があります。
実用的モデルは次のようになります。
- Web アプリロール: ユーザー要求の背後にあるテーブルの制限された読み取りと書き込みアクセス。
- ワーカーロール: ジョブを実行するために必要なレコードへのアクセス。
- 分析ロール: カレーションされたデータセットに直接識別子を削除した場合の読み取り専用アクセス。
- ブレークガラス管理者ロール: 短期の承認されたアクセスと強力なログとレビューとともに。
This pillar がデータ変換と組み合わせると、より強力になります。チームがマスクされたデータやデータの量を減らしたデータで仕事を実行できる場合、フルプロダクションの値ではなくそれを使用するようにしてください。規制された健康データの場合、 PHI の脱識別 は、有用なアクセスと不必要な露呈の差です。
データベースのシークレットは同じ規律を必要とします。ストレージの制御を強化するチームがCIログ、モバイルビルド、またはサポートスクリプトに機械認証情報を散らばしている場合、依然として攻撃の幅が広いままです。同様の運用習慣は、 API キーのアプリストアの準拠、特にモバイルアプリとバックエンドサービスが信頼の境界を共有する場合に、
監査は、制御が実際に存在するかどうかを示します。
検証できないポリシーはただの願望です。
監査トレイルは、インシデントの際に重要な質問に答えます。どのアイデンティティがレコードを読み取ったか。どのロールがパーミッションを変更したか。どのエクスポートジョブがデータを移動したか。どのキーが暗号化されたアーカイブを復号したか。彼らはまた、遅いドリフトを暴露します。サービスアカウントが必要としないテーブルに触れるようになったことなど。
有用な監査カバレッジには、通常、以下が含まれます。
- 認証アクティビティ: 正常ログイン、失敗ログイン、トークン使用、管理セッション。
- 認証変更: 許可、削除、ロール作成、ポリシーエディット、スキーマ変更。
- 敏感なアクセスパターン: 大量読み取り、大量エクスポート、不審なクエリパス、予期せぬ時間帯またはソースネットワークからのアクセス。
- 鍵管理イベント: 鍵の作成、回転、暗号化失敗、無効化されたバージョン、KMSまたはシークレットストアのポリシー変更。
ロギングの有効期間は重要です。レビューも重要です。ログが有効期限切れになる前に誰かが調査するのを待つのではなく、または既存の侵害のある場合にのみ特権変更を確認するのではなく、監査システムは紙上のもの以上に実際に存在することはありません。
ここでは実装の詳細が抽象化される前に、良い解説があります。
敏感なデータを防御できない場所から排除することが重要です。
最小限の努力で最も大きなセキュリティの勝利を得るチームは、多くのチームです。
データを少なく保管し、保管期間を短くし、複製を少なくし、特定の機能が年齢範囲のみ必要な場合には、生年月日を完全に保存しないようにし、サポートが最後の4桁のみが必要な識別子を露出しないようにし、テスト環境では実際の個人データが必要ない場合には、生産環境のバックアップをテスト環境に復元しないようにし、それを一時的なものと呼ぶのではなく呼びなさい。
このことは、実行上の慣行でもあります。保持スケジュールには、強制が必要です。古いエクスポートには、削除が必要です。下流システムには、リスクが増加するたびに検索インデックス、キャッシュ、データレイク、モバイルストレージ、そしてアドホックCSVファイルに敏感なフィールドが複製されるため、レビューが必要です。Capacitorアプリケーションでは @capgo/capacitor-data-storage-sqlite そして @capgo/capacitor-fast-sql は暗号化されたアプリケーション側のパERSISTENCEを提供できますが、まだ、すべてのローカルストレージに保存しないものを決める必要があります。
これらの柱の目的は、最初の日から完璧ではありません。キー回転、従業員の変更、インシデント対応、バックアップの復元、製品の成長など、ストレージシステムが防御可能なままになることです。通常、安全なデータベースストレージは成功または失敗するところです。
暗号化の実践的な実装パターン
システムごとに暗号化のパターンはありません。正しい選択は、どのものを保護するか、誰がそれを検索する必要があるか、そしてチームがサポートできる複雑さのレベルによって決まります。誤りは、最も強力な音を響かせるパターンを選んで、それを悪く実装することです。
TDEは最速のベースラインです
透過型データ暗号化、またはTDE、は通常、最初のステップで最も簡単な場所です。データベースエンジンはディスク上のファイルを暗号化し、エンジンがメモリに読み込むときに暗号化を解除します。アプリケーションはcodeの変更が必要ありません。
This is a strong baseline for:
- 全データベース保護
- ストレージレベルの法令適合性要件
- 盗難されたディスク、スナップショット、またはRAWファイルアクセスによるリスクの削減
TDEはすべてを守りません。有効なデータベースアクセスを取得した攻撃者に対して、エンジンは依然として暗号化されたデータを提供します。 したがって、TDEはストレージの侵害に対処するのに役立ちますが、有効な資格情報の不正使用には対処しません。
アプリケーションレベルの暗号化は、最も重要なフィールドを保護します
アプリケーションレベルの暗号化は、データがデータベースに到達する前に実行されます。 codeは選択されたフィールドを暗号化し、暗号化されたテキストをストレージに書き込みます。 これは、政府ID、銀行口座、復元シークレット、またはプライベートノートなどの特に敏感な列に対して特に効果的です。
その追加の制御は、次のトレードオフを伴います:
- 複雑さの所有権: キー選択、暗号化ライブラリ、ローテーション動作、エラー処理
- クエリが難しくなります: 厳密な一致、部分検索、インデックス作成が設計上の問題になります。
- 開発者には規律が必要です： 1 つのマイグレーション スクリプト内のショートカットは、モデル全体を回避する可能性があります。
シンプルな偽コード パターンは次のようになります：
| ステップ | アクション |
|---|---|
| 1 | リクエストからプレーン テキスト フィールドを読み取ります |
| 2 | データ暗号化キーを取得するためにキー サービスに問い合わせるか、ローカルにラップされたキーを使用します |
| 3 | アプリケーション内でフィールドを暗号化します |
| 4 | データベースにシフタテキストとメタデータを保存します |
| 5 | 承認された読み取りパスでのみ、シフタテキストを復号します |
ローカル アプリケーション パERSISTENCE の場合、同じ設計上の質問が適用されます。デバイス上でオフライン トークンや敏感な同期状態を保存する場合、デフォルトではモバイル ストレージが安全であると仮定しないでください。プラットフォームに合わせたパターンを使用してください。例えば、 オフライン トークンの安全な保存については Capacitor を参照してください.
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
__CAPGO_KEEP_2__
__CAPGO_KEEP_3__
- __CAPGO_KEEP_4__ __CAPGO_KEEP_5__
- __CAPGO_KEEP_6__ __CAPGO_KEEP_7__
- __CAPGO_KEEP_8__ __CAPGO_KEEP_9__
- __CAPGO_KEEP_10__ __CAPGO_KEEP_11__
- __CAPGO_KEEP_0__.
フィールドのアドバイス: 長期間のマスターキーをすべてのアプリケーションサーバーに公開せずに強力な隔離を実現するために、エンベロープ暗号化を使用してください。
このパターンは、パフォーマンスと制御をバランスさせるためによく見られます。アプリケーションは実際の暗号化作業で短期間のデータキーを使用し、KMSまたはHSMはマスターキーをwrapおよびunwrapするために使用するマスターキーを保護します。
暗号化パターン比較
| パターン | 実装の複雑さ | パフォーマンスの影響 | 適切なもの |
|---|---|---|---|
| ディスクまたはボリューム暗号化 | 低 | 低 | サーバーと接続されたストレージのインフラレベル保護 |
| __CAPGO_KEEP_0__ | 低から中 | 低から中 | 最小のアプリケーション変更でデータベース全体の保護 |
| アプリケーションレベル暗号化 | 中から高 | フィールドの使用とクエリ設計によって異なる | 厳格な分離と高感度のカラムが必要 |
| エンベロープ暗号化 | 中から高 | 中 | 強力な鍵隔離とスケーラブルな鍵管理が必要なシステム |
実用的ルールは簡単です。強力な基準であるTDEまたは管理中の暗号化を開始し、フィールドレベルまたはエンベロープ暗号化を追加するのは、データの感受性と脅威モデルが追加のエンジニアリングを正当化する場合のみです。
鍵とシークレット管理のマスター
侵害は通常、秘密の扱いに関する普通のミスから始まります。生産データベースは暗号化されています、バックアップが存在し、紙上ではアクセスが制御されているように見えます。すると、CIジョブはログにトークンを印刷する、エンジニアはサポートスクリプトで管理クレデンシャルを再利用する、または古い鍵がチームが作成した後も長く有効なままになるなど、エラーが発生します。
なぜ鍵とシークレット管理は運用慣行であり、セットアップタスクではないのか
データベースが不適切に管理された鍵で暗号化されていると、サーバールームの鍵がドアハンドルの上に掛けられているようなものです。政府のガイドラインも同じことを指摘しています。エンコードだけでは、チームがKMSまたはHSMベースの鍵管理、最小限の特権アクセス、回復計画を省略した場合、ギャップを埋められません。NSAとパートナーのガイドライン「クラウドデータのセキュリティ」に記載されている チームが間違っている所.
インシデントレビューでは、よく見られるパターンは
ソースコードに__CAPGO_KEEP_0__
- Secrets in source code: コピーされた設定ファイルにシークレット
- Secrets in copied config files: ファイルはラップトップ間で送信され、共有フォルダに保存され、急いで修正中にコミットされます。
- 環境変数の制御が弱い: 便利ですが、ビルドログ、シェル履歴、クラッシュレポート、または広範な実行時間許可によって頻繁に公開されます。
- ローテーションへの所有権なし: キーは、チームが再発行、ロールアウト、ロールバック計画を所有しないため、数年間存在します。
- 共有高特権シークレット: アプリケーション、エンジニア、自動化に使用される1つの資格情報があり、監査と抑制が困難になります。
アプリケーションとインフラストラクチャのシークレットの保存方法を標準化する場合、秘密の管理の実践的なガイドです。 安全な環境変数の管理 アドホックなシークレットのスプレッドを避けるためにチームが移動できるようにするのに役立ちます。
秘密の管理の良い例
使用する __CAPGO_KEEP_0__ 中央化されたポリシー、アクセス制御、監査ログ、スケジュールされたローテーションがカスタムハードウェア制御よりも重要な場合に使用してください。 リスク、法的要件、署名、鍵保護規則がハードウェア境界を特定することを正当化する場合に使用してください。多くのチームにはHSMが必要ありませんが、システムが暗号化解除操作を要求できるシステム、ポリシーを変更できる人間、そしてそのアクションがレビューされる方法については明確なルールが必要です。 暗号化のための短期間のデータキーをアプリケーションが管理し、KMSまたはHSMに保管されているvaultキーへのアクセスを厳重に制限します。
実際のインシデントを防ぐコントロールは、運用上のものです。
安全に実行可能なスケジュールでキーをローテーションします。
- ローテーションは、キーが侵害された場合に有効な期間を短縮しますが、応答が正常に機能する場合にのみです。 役割の分離:
- 顧客データを読み取るサービスが、鍵ポリシーを変更したりログを無効にしたりする権限を持たないようにします。 重要な鍵イベントをログします。
- 鍵の作成、ローテーション、暗号化解除要求、失敗したアクセス試行、ポリシー変更など、すべてのイベントが可視化されます。 __CAPGO_KEEP_0__
- テスト再暗号化パス: アプリケーションデータの再暗号化よりも、ラップする鍵を回転させることが通常は容易ですが、両方にロールバックステップと実行計画が必要です。
- 古いシークレットを意図的に無効化して引退させる: 切断後、古い資格情報を削除して、静かに裏口になる可能性を防ぎましょう。
CI/CDは、生産時実行と同じ規律を必要とします。ビルドシステムは広範なアクセスと弱い可視性を持っており、シークレットの漏洩が一般的な場所です。真剣に取り組むチームは通常、CI/CDパイプライン内でのシークレットの管理を正式化しています。 CI/CDパイプラインの資格情報を一時的な例外として扱うのではなく。 1つのルールは簡単です。アプリケーション__CAPGO_KEEP_0__は、信頼できるシステムから暗号化操作を要求し、環境内で未加工のマスターキーを運ぶのではなく。
One rule is simple. Application code should request cryptographic operations from trusted systems, not carry raw master keys around the environment.
設計するための頑丈なバックアップと復元戦略
バックアップは安全なデータベースストレージの一部であり、別の管理タスクではありません。生産環境が保護されている場合、バックアップが保護されていない場合、攻撃者は容易なパスを選択します。独立したストレージガイドラインでは、バックアップと復元システムを生産環境と同じ保護レベルで実行することを推奨しています。ransomwareやマルウェアのインシデントは、安全でテストされたバックアップが唯一の復元可能なパスである可能性があるため、安全なテストされたバックアップが残る可能性があります。
独立したストレージガイドラインでは、バックアップと復元システムを生産環境と同じ保護レベルで実行することを推奨しています。ransomwareやマルウェアのインシデントは、安全でテストされたバックアップが唯一の復元可能なパスである可能性があるため、安全なテストされたバックアップが残る可能性があります。
独立したストレージガイドラインでは、バックアップと復元システムを生産環境と同じ保護レベルで実行することを推奨しています。ransomwareやマルウェアのインシデントは、安全でテストされたバックアップが唯一の復元可能なパスである可能性があるため、安全なテストされたバックアップが残る可能性があります。 Hypertecの安全なデータストレージガイドライン.
バックアップには独自のセキュリティ境界が必要
バックアップ設計が頑丈であるには、いくつかの特性が必要
- バックアップは送信中および休眠中で暗号化される
- バックアップの資格情報は生産資格情報とは別個である
- 削除および保持コントロールは通常のアプリケーションアクセスよりも悪用しにくい
- 復元先は影の生産環境ではなく、弱いコントロールを持たない
共通の失敗モードは、暗号化されたバックアップを保存することです。ただし、同じ侵害された生産ロールが削除することを許可します。もう一つは、復元先に広範なエンジニアアクセスとログなしの環境に復元することです。復旧パスは主なパスと同じ程度の注意が必要です。
復元テストは実際のコントロール
テストされていないバックアップは単に望ましいストレージ
復旧に成功するチームは、単にバックアップジョブが完了したことを確認するのではなく、復元が機能し、復元されたデータが使用可能であり、必要なときに暗号化キー、接続設定、および依存サービスがすべて整合していることを証明します。
実用的復旧プログラムには
- 定期復元演習 __CAPGO_KEEP_0__に隔離された環境に
- データベース復元後、ファイルの復元のみでは機能確認ができない データベース復元後のアプリケーション機能の確認
- 暗号化されたバックアップが復元できるように、キーが利用可能であることを確認 復元されたシステムにアクセスして、機密情報がインシデント中広く公開されないようにする
- 復元されたシステムで機密情報が広く公開されないようにする バックアップはあなたを救うものではない。復元が成功すればあなたを救う
バックアップの作成のみテストし、復元のテストをプレッシャーをかけずに実行しない場合、復元戦略が検証されていない
復元戦略が検証されていない
開発者向けセキュアなデータベースストレージのチェックリスト
設計レビュー、リリースレビュー、インシデント後クリーンアップの際にチームが使用するチェックリスト
設計
- 機密フィールドを明確に識別しているか: 個人情報、認証情報、金銭情報、保存規則の対象となるものなど。
- どのデータを保存しないことを決定しているか: 必要ないフィールド、または下流チームが避けるべきコピーなど。
- データがどの場所でどのように保存されるかをマッピングしているか: 生産、ステージング、ログ、エクスポート、分析システム、バックアップ、クライアントデバイスなど。
実装
- データは、データベース、レプリカ、バックアップパスで、休止中でも暗号化されているか: アプリケーションとサービスロールは、厳密にスコープされているか:
- Are application and service roles scoped tightly: 通常のアプリケーション トラフィックには共有されたスーパーユーザーがない。
- 秘密と暗号化キーは code と緩い構成外でどのように扱われるか。 制御されたアクセスと監査可能性。
- 敏感なアクセスと特権変更のログはどのように行われるか。 防御者がクエリすることができる中央の場所で。
オペレーション
- キーローテーションとシークレットのレビューは通常のオペレーションの一部であるか。 年間の混乱ではない。
- 定期的に復元テストを行っているか。 復元されたシステムで復元されたアプリケーション起動、復元されたシステムのアクセスレビュー、暗号化解除を含む。
- データ スプラウルは定期的に監査されている。 ステージング コピー、サポート エクスポート、開発 データセット、および忘れられたバックアップ ロケーション。
安全なデータベースストレージはプロジェクトのフェーズではありません。 それが繰り返される習慣です。
よくある質問
クラウドプロバイダのデフォルト暗号化は十分でしょうか
それが強力なベースラインではありますが、完全な戦略ではありません。 デフォルトの暗号化はストレージメディアとマネージドサービスを保護しますが、オーバープライバシーアクセス、コピーされたデータセット、弱いバックアップ制御、または悪いキー管理を解決することはありません。
暗号化はデータベースのパフォーマンスに影響を与えますか
はい、場合によっては。 影響の程度はパターンによって異なります。 インフラストラクチャとデータベースレベルの暗号化は、一般にアプリケーション複雑さが少ないことが多いです。 フィールドレベルの暗号化は選択したデータに対して強い制御を提供しますが、インデックス作成、フィルタリング、検索を複雑にする可能性があります。 仕事ロードに基づいて広範なロールアウトを計画する前に測定してください。
SQLとNoSQLシステムでは異なりますか
原則は同じです。 まだ暗号化、最小限の特権、監査、キー管理、テストされた復元が必要です。 実装の詳細は異なります。 ドキュメントストア、キー値ストア、関係システムは異なるアクセスモデルとクエリ動作を露出します。
トークナイズとは暗号化とはどのように異なりますか
暗号化はデータを変換し、権限のあるシステムが正しいキーで復号化できるようにします。 トークナイズは機密情報を代替値に置き換え、元のデータを別の場所に分離します。 トークナイズはアプリケーションワークフローで露出を減らすことができますが、システム設計の複雑さを追加し、強いストレージ制御の必要性を排除することはできません。
Capgo helps teams ship fixes to Capacitor and Electron apps quickly, with signed web bundle delivery, rollout controls, rollback protection, and release observability. If your incident response plan depends on getting client-side fixes out fast after a storage, auth, or API mistake, Capgo ストレージ、認証、または__CAPGO_KEEP_2__のミスによるクライアントサイドの修正を迅速に配信できるようにするため、インシデント対応計画が依存している場合
