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