夜遅くリリースをプッシュし、確認したあと、プライベートリポジトリから出たはずのクレデンシャルを発見した。もしかして、データベースのパスワードだった。もしかして、広い権限を持つクラウドアクセスキーだった。どちらにしても、問題は単に誰かがログインできることだけではない。実際の問題は、データベースセキュリティがログイン問題とみなされていることだ。実際は、データベースのライフサイクル問題だ。
それは、実際のシステムで見られる。チームは暗号化を一度実行し、完了とみなす。バックアップを実行するが、復元テストを実行しない。管理サービスアカウントを作成し、便利さのために忘れる。生産環境をロックダウンし、ステージング環境にコピーした顧客データを残す。モバイルアプリやウェブアプリを開発している場合、データベースのセキュリティはすべてをカバーする必要がある: 主要なデータベース、レプリカ、エクスポート、ログ、バックアップ、すべてのキーを制御するもの。
あなたも次のアプリの認証を解決している場合 認証とストレージのセキュリティを解決するのは異なるエラーのモードです認証は誰が入るかを決定します API security standards for app store compliance.
顧客向けアプリを配信するチームにとって、ストレージの決定を隣接する制御と合わせることも価値があります __CAPGO_KEEP_0__ セキュリティ基準 アプリストアの適合性緊急性は理論的ではありません
2020年には、世界のデータ生産量は64.2ゼタバイトに達し、2025年には180ゼタバイトに達する予想がありました
- Edge Deltaのデータストレージサマリー
- データベースの脅威モデルを理解する
- 安全なデータベースストレージの基本原則
- 実践的な暗号化実装パターン
- マスターキーとシークレットの管理
- バックアップと復元の設計
- 開発者用セキュアデータベースストレージチェックリスト
- よくある質問
データベースのセキュリティはパスワードだけではありません
パスワードはエントリポイントを保護しますが、資格情報が漏洩したり、スナップショットがコピーされたり、内部サービスが許可されていないテーブルにアクセスしたりすると、データは保護されません。 したがって、安全なデータベースストレージには層が必要です。
古いメンタルモデルは単純でした: データベースをファイアウォールの後ろに置き、強いパスワードを要求し、外部者を遠ざけます。 しかし、このモデルはクラウドシステム、モバイルバックエンド、モダンCI/CDパイプラインでは機能しません。 データはサービス間で動きます。 エンジニアは一時的なエクスポートを作成します。 分析ジョブはレコードを複製します。 バックアップシステムは異なるインフラストラクチャ上でコピーを保存します。 攻撃者はデータベースエンジン自体を破る必要はありません。 ただし、キーを盗んだり、APIトークンを悪用したり、レプリカの制御が弱いものにアクセスしたりすることができます。
セキュリティは静かなパスで失敗します
最も損害のあるストレージの失敗は最初はドラマチックではありません。 それらは普通のようです。
- 開発者にとっての便宜は生産リスクになります: 共有管理資格がスクリプトによって再利用されるのは、ローテーションすると展開が破壊されるためです
- Aデータセットのコピーは、管理の外れます: 生産レコードは、ステージングにクローンされ、QAがバグを再現できるようにします。
- Aバックアップは弱点になります: 生産には強力な制御がありますが、復元バケットまたはスナップショットポリシーにはありません。
実用的なルール: 攻撃者が読み取れるデータに唯一の障壁が資格情報だけの場合、安全なストレージを持っていません。単一の障壁を持っています。
防御は資格情報の悪用を乗り切らなければなりません
マイクロソフトのクラウドガイドラインでは、エンクリプションをトランザクション中とリストア中、最小限の特権アクセス制御、非正規のアクティビティの監視を含むクラウドデータセキュリティのベストプラクティスを推奨しています。 実際のインシデントは、有効なアクセスを誤用したことから始まることが多いため、ベースラインは正しいです。実践で機能することは、面白くないもので、均一です。データベースファイルを暗号化してください。接続を暗号化してください。サービスロールを分割してください。立ち往生している管理者アクセスを削除してください。機密情報の操作をログしてください。アクセスパターンが通常の使用とは異なるものにアラートを発生させてください。どれも魅力的なものではありませんが、実際の侵害を防ぐためには効果的です。
実用的な方法で考えると、物理的なセーフティボックスと同じです。セーフティボックスのドアは重要です。同封ロック、カメラ映像、訪問者ロジック、BOXを開けるためのポリシーも重要です。安全なデータベースストレージも同様です。パスワードはただの前ドアです。
__CAPGO_KEEP_0__
脆弱性を理解する
まずはシステムの可能性のある欠陥をマップすることから始めましょう。データベースのセキュリティの脅威モデルには、学術的なものではなく、誰が敏感なデータにアクセスする可能性があり、それをどのように行うか、そして成功した場合に何が起こるかを示すものが必要です。
敏感なデータはほとんどが1つの整理されたプロダクション データベースに存在しません。現代のガイドラインでは、敏感情報がコピー、バックアップ、ログ、開発環境などに存在する可能性があるため、主なデータベース外で失敗が発生する可能性があるため、発見とポジチュア管理を強調しています。 CloudflareのCloud Data Security and Posture Managementの概要、で説明されているように。 したがって、インシデント計画には、ベンダーエクスポージャーとコピーされたデータセットなどのシナリオを含める必要があります。これは、第三者による侵害対応のベストプラクティス 、が関連する場所でもあります。アセットから始めましょう
まずは重要なものをリストしましょう。
ほとんどのアプリチームにとって、重要なアセットは次のとおりです:
顧客情報
- 顧客情報 例えば、プロフィール、注文履歴、決済関連のメタデータ、または健康関連のコンテンツなど。
- 認証材料 例えば、パスワードハッシュ、セッションレコード、リフレッシュトークン、またはAPIのシークレット。
- 運用データ 例えば、監査ログ、ジョブキュー、管理者メモ、サポートエクスポート。
- 復旧資産 例えば、スナップショット、論理的なダンプ、ポイントインタイムログ、または暗号化キー。
最後のアイテムはチームが思っているよりも重要です。攻撃者がバックアップを削除したり、暗号化を解除するためのキーにアクセスしたりすると、復旧ストーリーが崩壊します。
最も重要な3つの脅威のバケット
開発者と一緒に使用するシンプルなモデルは3つのバケットがあります。
外部の攻撃者
これは最初に考える人々が考えているバケットです。SQLインジェクション、盗まれたAPIトークン、漏洩したクラウドクレデンシャル、公開された管理パネル、脆弱な依存関係。共通のテーマは、データへのアクセスを得る外部の攻撃者です。
質問すること:
- アプリを通じてデータベースにアクセスできる可能性はありますか?
- 盗まれたサーバークレデンシャルが、サービスが必要とするものを超えて何を読むことができますか?
- コピーされたスナップショットは、独自に読み取ることができますか?
内部リスク
これには、悪意のある内部者や、権限が多すぎる従業員も含まれます。サポートエンジニアはチケットを解決するためにデータをエクスポートします。契約者はローカルコピーを保持します。プラットフォーム管理者は、仕事の要件に合わないにもかかわらず、生産環境の行を読むことができます。
役割ベースのアクセスと、敏感な読み取りを可視化するための監査トレイルが役立ちます。
もしも、顧客レコードにアクセスした人物、いつアクセスした、そしてそのアクセスが許可された理由を答えられない場合は、データベースの制御は見た目よりも弱いことになります。
誤って公開されること
これは、迅速に動くチームで最も一般的なカテゴリです。設定が不十分なストレージバケット。ライブデータでシードされたステージング環境。トークンや個人情報を含むデバッグログ。トラブルシューティングのために低セキュリティ環境に復元されたバックアップ。
誤って公開されることは、強力なストレージセキュリティがオペレーショナルであることを意味します。1 つの設定で解決することはできません。データ分類、ガードレール、レビュー、定期的なクリーンアップで解決する必要があります。
安全なデータベースストレージの基本原則
Aの侵害はまれに大きな失敗から来る。通常は、連続する普通のミスから来る。バックアップは間違ったアカウントにコピーされる。サービスは必要以上の権限を取得する。古いキーは数ヶ月間有効なままになる。なぜなら、キーを回転させることが延期されるからだ。安全なデータベースのストレージは、システムが変化するたびにその連鎖を何回も断ち切る必要がある。
私は作業を4つの柱に分けている:暗号化、認可、監査、最小化。バックアップと復元も重要だが、独自の運用対象として扱うべきだ。復元されたデータは、誰が読むことができるか、どのキーで復元できるか、どこに保存されるかをテストしないと、新しい脆弱性につながるからだ。
暗号化は盗難されたデータの価値を下げる。
暗号化は時間を稼ぎ、影響を軽減する。ディスクのスナップショット、RAWバックアップファイル、内部ネットワークのトラフィックを取得したとしても、暗号化されたデータは顧客レコードに変換するのは難しい。
暗号化はデータベースファイル、スナップショット、バックアップアーティファクトを保護する。TLSはアプリケーションサーバー、プロキシ、データベースエンジン間の接続を保護する。NISTはSP 800-111と関連するデータ・アット・レストの推奨事項で両方の制御を扱っている。 backup and recoveryも重要だが独自の運用対象として扱うべきだ。復元されたデータは誰が読むことができるか、どのキーで復元できるか、どこに保存されるかをテストしないと、新しい脆弱性につながるからだ。.
実行上のトレードオフは理論的ではない。エンコードは、キー管理がデータパスから分離され、長期にわたって維持される場合にのみ有効である。エンベロープエンコードは、ビルディングマスターキーとロックされたオフィスキーのように機能する。マスターキーを保護するキーマネジメントサービスがあり、そのマスターキーは短期間のデータキーの暗号化に使用される。実際のレコードまたはファイルのために使用されるデータキーの暗号化が行われる。設計は、回転中に露出を制限し、すべてを一度に書き換えることなくキー材料を削除または置き換えることを容易にする。
チームは、エンコードを有効にし、それ以上行かないとトラブルになる。キーがどこに住んでいるか、誰が使用できるか、回転が計画されているか、古いバックアップが忘れられたキーバージョンに依存しているかを確認する。
アクセス制御は、爆発半径を制限する。
権限は、組織図ではなくアプリケーション境界に従うべきである。
チェックアウトのAPIのデータベースロールは、給与データを読むことができないようにする。バックグラウンドワーカーは、早い段階の移行のために便利だったが、スキーマ変更権を持たないようにする。サポートツールは、広範なテーブルへのアクセスではなく、フィルタされたビューまたは承認された手順を使用する。
実用的モデルは次のようになる。
- Webアプリロール: ユーザー要求の背後にあるテーブルの制限された読み取りと書き込みアクセス。
- ワーカーロール: ジョブを実行するために必要なレコードへのアクセス。
- 分析ロール: カレーションされたデータセットへの読み取り専用アクセス。可能な限り直接識別子を削除する。
- セキュアなデータベースストレージ 緊急時の管理者ロール:
短期間の承認されたアクセスと強力なログとレビュー. データ変換と組み合わせると、この柱が強くなる。チームがマスクされたデータやデータの量を減らしたデータで仕事ができる場合、フルプロダクションの値ではなく、そのバージョンを与える。規制された健康データの場合 PHIの非特性化
は、有用なアクセスと不必要な露出した差です。 データベースの秘密に対して同じ規律を適用する必要があります。CIログ、モバイルビルド、またはサポートスクリプトに散らばっているマシン認証情報を引き続きチームがストレージ制御を強化している場合でも、広範囲にわたる攻撃パスが残っています。同様の運用慣行は、特にモバイルアプリとバックエンドサービスが信頼境界を共有する場合に、API キーセキュリティのアプリストアの準拠にも当てはまります。監査は、制御が実際に機能しているかどうかを示します。
検証できないポリシーはただの願望です。
監査トレイルは、インシデントの際に重要な質問に答えます。どのアイデンティティがレコードを読み取った。どのロールが権限を変更した。どのエクスポートジョブがデータを出力した。どのキーが暗号化されたアーカイブを復号した。監査トレイルは、サービスアカウントが以前必要としなかったテーブルに触れるようになったことを示す遅いドリフトも暴きます。
有用な監査カバレージには、
通常、以下のものが含まれます。
- 認証活動: 正常ログイン、失敗ログイン、トークン使用、管理者セッション。
- 承認変更: 許可、取消、ロール作成、ポリシーエディット、スキーマ変更。
- 敏感なアクセスパターン: 大量読み取り、大量エクスポート、不正なクエリパス、予期せぬ時間帯またはソースネットワークからのアクセス。
- 鍵管理イベント: 鍵の作成、回転、暗号化失敗の試行、無効化されたバージョン、KMSまたはシークレットストアのポリシー変更。
保持期間は重要です。レビューも重要です。ログが期限切れになる前に誰かが調査するのを待つのではなく、特権変更がすでに侵害が発生している場合にのみ誰かが確認するのではなく、監査システムは紙上の存在感だけが残るのを防ぐために監査システムが存在する必要があります。
実装の詳細が抽象化される前に、ここでは良い解説があります:
敏感なデータを防御できない場所から排除することが最小限のエンジニアリング努力で最大のセキュリティ勝利を得ることができます。
最小化は、敏感なデータを防御できない場所から排除することです。
データを少なく。データを保管する時間を短く。データを複数の場所にコピーする回数を減らす。特定の機能が年齢範囲のみを必要とする場合、生年月日を完全に保存しない。サポートがIDの最後の4桁のみを必要とする場合、IDの完全なフィールドを公開しない。テスト環境が実際の個人データを必要としない場合、生産バックアップを復元してそれを一時的なものと呼ぶことはない。
このことは、運用上の慣行でもある。保持スケジュールには、強制が必要である。古いエクスポートには、削除が必要である。検索インデックス、キャッシュ、データレイク、モバイルストレージ、CSVファイルなど、敏感フィールドを複製するたびにリスクが増加するため、下流システムにはレビューが必要である。Capacitorアプリケーションでは @capgo/capacitor-data-storage-sqlite そして @capgo/capacitor-fast-sql 暗号化されたアプリ側のパERSISTENCEを提供できるが、まだ、ローカルに保存することなく保存すべきものを決定する必要がある。
これらの柱の目的は、最初の日から完璧ではない。キー回転、従業員の変更、インシデント対応、バックアップの復元、製品の成長など、データストレージシステムが防御可能なものになるようにすることである。そうでなければ、安全なデータベースストレージは成功または失敗する。
暗号化の実践的な実装パターン
暗号化のパターンはシステムごとに1つではない。保護するもの、クエリする必要がある人、チームがサポートできる複雑さによって、正しい選択肢が決まる。誤りは、最も強い音を響かせるパターンを選んで、それを悪く実装することである。
TDEは最速のベースライン
透明データ暗号化, またはTDEは、通常、最も簡単な開始点です。データベースエンジンはディスク上のファイルを暗号化し、エンジンがメモリに読み込むときにファイルを復号します。アプリケーションは通常、codeの変更が必要ありません。
これは次の強いベースラインです:
- 全データベース保護
- ストレージレベルの合規性要件
- 盗難されたディスク、スナップショット、またはRAWファイルアクセスによるリスクの削減
TDEはすべてを保護しません。有効なデータベースアクセスを取得した攻撃者に対して、エンジンは依然として復号されたデータを提供します。そのため、TDEはストレージの侵害に対処し、正当な資格情報の誤用に対処しません。
アプリケーションレベルの暗号化は重要なフィールドを保護します
アプリケーションレベルの暗号化は、データがデータベースに到達する前に実行されます。codeは選択したフィールドを暗号化し、暗号化されたテキストをストレージに書き込みます。この方法は、特に政府ID、銀行口座、復元シークレット、またはプライベートノートなどの敏感な列に対してよく機能します。
その追加の制御は、次のトレードオフとともに実行されます:
- 複雑さの管理はあなたの責任です: 鍵の選択、暗号化ライブラリ、ローテーション動作、エラー処理。
- クエリの取得は難しくなります: 正確な一致、部分検索、インデックス作成が設計上の課題となる。
- 開発者は自律性を必要とします: 1 つのマイグレーション スクリプトのショートカットは、モデル全体を回避する可能性があります。
シンプルな擬似コードパターンは次のようになります:
| ステップ | アクション |
|---|---|
| 1 | リクエストからプレーンテキスト フィールドを読み取る |
| 2 | 鍵サービスからデータ暗号化鍵を取得するか、ローカル鍵をwrapする |
| 3 | アプリケーション内でフィールドを暗号化する |
| 4 | データを暗号化したシールとメタデータをデータベースに保存する |
| 5 | 承認された読み取りパスでのみデータを復号する |
ローカルアプリケーションの永続化の場合、同じ設計上の質問が適用される。デバイス上でオフラインのトークンや敏感な同期状態を保存する場合、デフォルトではモバイルストレージが安全であると仮定しない。プラットフォームに合わせたパターンを使用するようにし、__CAPGO_KEEP_0__で議論されたオフライントークンの安全な保存方法を参照する。 secure storage for offline tokens in Capacitor.
エンベロープ暗号化は脅威に見えるかもしれないが、実際は単純な考え方である。データを1つの鍵で暗号化し、その鍵を別の、より保護された鍵で暗号化するだけである。
安全な箱の中に書類を入れると想像してみよう。小さな安全な箱の鍵は、さらに保護された銀行のセーフを使用して暗号化される。もし誰かが書類の保存層を盗んだとしても、銀行のセーフの鍵を入手する必要がある。書類を開くには、さらに保護された鍵が必要になる。
一般的なフロー:
データ鍵を生成する
- レコード、ファイル、またはバッチ用にデータ鍵を生成する。 データを暗号化する
- データ鍵を使用してデータを暗号化する。 with that data key.
- データキーを Wrap KMS または HSM のマスターキーを使用して。
- 暗号化されたデータにラップされたキー メタデータを含む レコードまたはオブジェクトと共に保存。
- 承認された読み取りのみでラップ解除.
フィールドアドバイス: 長期間のマスターキーをすべてのアプリケーションサーバーに公開せずに強力な隔離を実現する必要がある場合に、エンベロープ暗号化を使用してください。
このパターンは、パフォーマンスと制御のバランスをとるためによく見られます。アプリケーションは、実際の暗号化作業に短期間のデータキーを使用し、KMS または HSM はラップとラップ解除に使用されるマスターキーを保護します。
暗号化パターン比較
| パターン | 実装の複雑さ | パフォーマンスの影響 | 最高の選択肢 |
|---|---|---|---|
| ディスクまたはボリュームの暗号化 | 低 | 低 | サーバーと接続されたストレージに対するインフラストラクチャレベル保護 |
| 透明データ暗号化 | 低から中 | 低から中 | データベース全体の保護に最小限のアプリケーション変更 |
| アプリケーションレベルの暗号化 | 中から高 | 使用するフィールドとクエリ設計によって異なる | 高度の機密性のあるカラムと厳格な分離の必要性 |
| 封筒暗号化 | 高い | 普通 | より強力なキー分離とスケーラブルなキー管理が必要なシステム |
実用的ルールは簡単です。強力なベースラインであるTDEまたは管理中の暗号化から始めます。フィールドレベルの暗号化または封筒暗号化は、データの機密性と脅威モデルが追加のエンジニアリングを正当化する場合にのみ追加します。
マスター キーとシークレット管理
侵害は普通のシークレット管理ミスから始まることがよくあります。生産データベースは暗号化されています、バックアップもあり、紙上ではアクセスが制御されているように見えます。するとCIジョブはログにトークンを印刷する、エンジニアはサポートスクリプトで管理クレデンシャルを再利用する、またはチームが作成したものとは関係のない古いキーが長く有効なままになるなどです。
そのため、キーとシークレット管理は運用慣行であり、セットアップタスクではありません。
キーを不適切に管理したデータベースは、ドアハンドルのアクセスバッジが付いたロックされたサーバールームと同じように動作します。政府のガイドラインも同じことを指摘しています。暗号化だけでは、チームがKMSまたはHSMベースのキー管理、最小限の特権アクセス、回復計画を省略した場合に、ギャップを埋めることができません。NSAとパートナーのガイドラインに記載されているように。 この点でチームが間違っている.
https://www.capgo.com/blog/ja/secure-database-storage/
インシデントのレビューでは、パターンはよく見られる:
- codeのソース内に秘密: ハードコードされたクレデンシャル、埋め込まれた証明書、または徐々にプロダクション依存の依存関係となるユーティリティスクリプト。
- コピーされた設定ファイル内の秘密: ノートパソコン間でファイルを渡す、共有フォルダに保存する、または急いで修正したときにコミットするファイル。
- 弱い制御のある環境変数: 便利ですが、ビルドログ、シェル履歴、クラッシュレポート、または広範な実行時許可によって公開されることが多い。
- ローテーションに所有権がない: キーは数年間存在するが、再発行、ロールアウト、ロールバック計画を所有するチームが存在しないため。
- 共有された高特権の秘密: アプリケーション、エンジニア、自動化ツールが共有するクレデンシャル、審査と抑制が困難になる。
アプリケーションとインフラストラクチャのシークレットを格納する方法を標準化している場合、秘密の取り扱いに関する実用的な参考資料 環境変数を安全に管理する 環境変数を安全に管理することは、チームがアドホックなシークレットの乱れから離れるのに役立ちます。
良い鍵管理の見本
使用するには 鍵管理サービス(KMS) 中央管理ポリシー、認可制御、監査ログ、定期的なローテーションがカスタムハードウェア制御よりも重要な場合に使用してください。 リスク、法的要件、署名、鍵保護規則が専用ハードウェア境界を正当化する場合に使用するには HSM
多くのチームには、HSMを全ての場所で使用する必要はありません。システムが復号操作を要求できるシステム、ポリシーを変更できる人間、そしてそのアクションがレビューされる方法については明確なルールが必要です。
エンベロープ暗号化はここで良いメンタルモデルです。短期間のデータキーをアプリケーションが暗号化作業に使用し、vaultキーはKMSまたはHSMに保管し、そこへのアクセスは厳重に制限されます。
- 実際のインシデントを防ぐコントロールは、運用上のものです。 キーを定期的にローテーションすることが安全に実行できるスケジュールで行うことが重要です:ローテーションは、キーが侵害された場合に有効な期間を短縮しますが、ただし、応答が可能なままであることを保証するために、応答、ジョブ、復元が正常に動作することを保証する必要があります。
- 責任分離: 顧客データを読み取るサービスは、鍵ポリシーを変更したりログを無効にしたりする権限を持たないようにする。
- 鍵イベントのログを有効にする: 鍵の作成、ローテーション、暗号化要求、失敗したアクセス試行、ポリシー変更がすべて可視化されるようにする。
- 再暗号化パスをテストする: Wrapping鍵のローテーションは、通常、再暗号化アプリケーションデータが容易ですが、両方にrunbooksとロールバックステップが必要です。
- 古いシークレットを意図的に無効にして廃止する: クローバー時間を残してから、古いクレデンシャルを削除して、静かにバックドアになるのを防ぐ。
CI/CDは、生産ランタイムと同じ規律を必要とする。ビルドシステムは広範なアクセスと弱い可視性を持っていることが多く、シークレットの漏洩の一般的な場所となっている。真剣に取り組むチームは通常、CI/CDパイプライン内でシークレットを管理することを公式化している。 シークレットを管理するというルールは単純だ。アプリケーションは、信頼できるシステムから暗号化操作を要求し、環境内でrawマスターキーを持ち運ばないようにする。 CI/CDパイプラインのクレデンシャルは、時期の経過とともに永久的な例外ではなくなり、正式な管理対象となる。
One rule is simple. Application code should request cryptographic operations from trusted systems, not carry raw master keys around the environment.
スタック内で最も強力な暗号化設計がもはや意味をなさなくなるのは、開発者、パイプライン、またはサポートツールがマスター キーを間違った場所にコピーできるようになったときです。
耐障害性の高いバックアップと復旧戦略の設計
バックアップは安全なデータベースストレージの一部であり、管理の別の作業ではありません。生産環境が保護されている場合、バックアップが保護されていない場合、攻撃者はより簡単なパスを選択します。
独立したストレージガイドラインでは、バックアップと復旧システムを生産環境と同じ保護レベルで構築することを推奨しています。ransomwareやマルウェアのインシデントは、安全でテストされたバックアップが唯一の復旧可能なパスであることがよくあります。 Hypertecの安全なデータストレージガイドライン.
バックアップには独自のセキュリティ境界が必要です。
耐障害性の高いバックアップ設計には、いくつかの特性があります。
- バックアップは転送中および休止中で暗号化されています。
- バックアップのクレデンシャルは生産環境のクレデンシャルと別々に管理されます。
- 削除および保持コントロールは通常のアプリケーションアクセスよりも悪用しにくくなっています。
- 復旧先は影の生産環境ではなく、弱いコントロールを持つ環境にはならない。
共通の障害モードは、暗号化されたバックアップを保存することですが、同じコンプロミットされた生産ロールが削除できるようにします。もう一つは、復旧先に暫定環境を復元し、広範なエンジニアアクセスとログなしの環境に復元することです。復旧パスは主なパスと同じ程度の注意が必要です。
テストの復元は、実際の制御です。
テストされていないバックアップは、ただ希望のストレージだけです。
復元がうまくいくチームは、単にバックアップジョブが完了したことを確認するだけではありません。実際は、復元が機能することを証明し、復元されたデータが使用可能であり、必要なときに暗号化キー、接続設定、および依存サービスがすべて整っていることを証明します。
実用的復元プログラムには次のことが含まれます。
- 定期的な復元演習 孤立された環境に。
- アプリケーションの機能の検証 データベースの復元後、ファイルの復元のみではありません。
- 鍵の利用可能性の確認 暗号化されたバックアップが復元できるようにするため。
- 復元されたシステムへのアクセスレビュー インシデントの際に敏感なデータが広く視認されるのを防ぐため。
バックアップはあなたを救わない。成功した復元があなたを救う。
あなたがバックアップの作成のみをテストし、圧力の下で復元をテストしない場合、あなたの復旧戦略を検証していない。ファイルが蓄積する場所がわかるだけである。
安全なデータベースストレージのための開発者チェックリスト
このチェックリストは、設計レビュー、リリースレビュー、インシデント後クリーンアップの際にチームが使用したいものです。
設計
- 敏感なフィールドを明確に識別しているか: 個人情報、認証材料、財務記録、保存規則の対象となるものなど。
- 保存しないことを決定しているか: 必要ないフィールド、そして下流チームが避けることができるコピーなど。
- データがどの場所で生きているかをマッピングしているか: 生産、ステージング、ログ、エクスポート、アナリティクスシステム、バックアップ、クライアントデバイスなど。
実装
- データは、データベース、レプリカ、バックアップパスで、保存中および転送中で暗号化されているか: データベース、レプリカ、バックアップパスの暗号化
- アプリケーションとサービス ロールは、厳密にスコープされているか: 通常のアプリケーション トラフィック用に、共有されたスーパーユーザーは存在しない。
- シークレットと暗号化キーは、code と汚れた構成から外部で管理されているか: 制御されたアクセスと監査可能性とともに。
- 敏感なアクセスと特権変更のログは、検索できる中央の場所で記録されているか: オペレーション
鍵の回転とシークレットのレビューは、通常のオペレーションの一部として行われているか:
- 年間の混乱ではなく not an annual scramble.
- データベースの復元を定期的にテストしますか： 復元されたシステムで、復元、復元後のアプリケーション起動、データアクセスのレビューを含む
- データの拡散を継続的に監査しますか： ステージングコピー、サポートエクスポート、開発用データセット、忘れられたバックアップの場所
良いセキュアなデータベースの保存はプロジェクトのフェーズではありません。定期的な慣行です。
よくある質問
ページ/エリア: Capgo Builder / ネイティブクラウドビルド製品ページ。役割: セクションまたはページヘッダー。メッセージキー `native_build_faq_title` (ネイティブビルドFAQタイトル)。| ページ/エリア: ホームページの問題/解決セクション。役割: セクションまたはページヘッダー。見られる場所: page premium-support.astro。メッセージキー `ps_faq_title` (Ps FAQタイトル)。
クラウドプロバイダーのデフォルトの暗号化は十分ですか
ベースラインは強いですが、完全な戦略ではありません。デフォルトの暗号化はストレージメディアとマネージドサービスを保護しますが、過度に権限のあるアクセス、コピーされたデータセット、弱いバックアップ制御、または不十分なキー管理を解決しません。
暗号化はデータベースのパフォーマンスに影響を与えますか
はい、場合によっては。パターンによって影響が異なります。インフラストラクチャとデータベースレベル暗号化は、通常、複雑さの低いアプリケーションです。フィールドレベル暗号化は、選択されたデータに対して強い制御を提供しますが、インデックス、フィルタリング、検索を複雑にする可能性があります。ワークロードに影響を与える前に、広範なロールアウトを計画してください。
これはSQLとNoSQLシステムの場合に異なりますか
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
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_1__
