開発中の開発者がデータを漏洩するのを防ぐ方法はありますか？
私はしばらくの間、スタートアップ企業と働いています。彼らは過去にいくつかの無謀な開発者の影響を受けました。実際にすぐに改善したい領域の1つは、データベースの読み取りを必要とする開発者にタスクを割り当てるときに、不要なフィールドがAPIシステムによって返されないようにすることです。
言い換えると、開発者がデータストアから不要なフィールドを取得するのを防ぎ、通知する保護層が必要です。
私がこのAPIに取り組んでいるとしましょう：
/api/v1/user/credentials
ここで実際に必要なのはユーザー名フィールドだけですが、間違いを犯し、ユーザーのパスワードを取得して返すようにデータベースクエリを書き込むこともありますが、これは明らかに望ましくない動作です。
これは、テストケースとシナリオを作成することである程度防ぐことができますが、その間に何らかのスキーマ検証を使用する必要があるようです。あるいは、開発者がデータベースに直接クエリできないように、データベースアクセス用のインターフェイスを定義する必要があるかもしれません。
開発中の開発者がデータを漏洩するのを防ぐ方法はありますか？
大規模な組織では、データベースのさまざまな部分に対してさまざまなグループの人々にさまざまなアクセスレベルを設定することが理にかなっている場合があります。そのため、ほとんどのリレーショナルデータベースは通常、アクセス権管理のためのツールを提供しています。たとえば、ユーザーテーブルでの資格情報の取得を制限する場合は、信頼できるユーザーに、ユーザー名のみを返すビューをユーザーテーブルスキーマに追加させ、このユーザーにのみユーザーテーブルに直接アクセスする権限を割り当てることができます。 、他のすべては直接ビューにのみアクセスできます。
しかしながら：
データベースの各フィールドはおそらく使用されますどこか。そのため、フィールドにアクセスできるかどうかをフィールドごとに決定し、その権限を管理する必要があります。それは大きな官僚的なオーバーヘッドを引き起こす可能性があります。結局のところ、誰かがどこかにクエリを書き込む必要があり、その人を信頼する必要があります。
資格情報はneverをプレーンテキストでDBに保存する必要があります。不可逆的なハッシュとしてパスワードを保存することをお勧めします
問題に対処するための単なる技術的手段以外の手段があります。「コードレビュー」を聞いたことがありますか？特にデータベースクエリの場合は、信頼できる人にコードの校正を依頼することをお勧めします。
機密データに注意する義務を与えることについて、開発者との契約にも何かがあるはずです。
データベースへのアクセスを開発者に制限するほど、開発者の仕事を妨げることになります。
実行する必要がある対策は、データの機密性に依存します。これに対するすべての解決策は「1つのサイズで適合」することはできません。また、組織によっても異なります。自分の会社に3人の信頼できる開発者がいて、他の会社からのプロジェクトに一時的に提供されている30人がいる場合、3人の開発者が他の30人に安全なAPIを提供できるようにするのは理にかなっています。しかし、組織がそれほど大きくなく、開発者が3人しかいない場合、導入するオーバーヘッドはおそらく価値がありません。
伝統的な考え方を持つDBAが極端に「開発者にSQLの作成を許可せず、すべてをストアドプロシージャにラップすることはできない」と言って、さまざまな慣習が見られます。私が現在慣れている環境に対する私の答えは「はい、しかし...」です。理由のいくつかを以下に示します（いくつかの点で実際には同じ理由です）。
- アジャイル開発方法論は「垂直」スライスを好むことがよくあります-単一の開発者がエンドユーザーの価値を備えた機能の完全な部分を開発します。これにより、開発者は自分がやっていることの目的と価値を理解し（そしてそれを顧客が望むものに関連付けることができ）、作成したコードがその目的に適合していることを確認し、フィードバックループを短縮し、コードが実際にいつ完了したかを知ることができます。など。潜在的に、それはよりやる気を起こさせる可能性もあります-動機づけは、重要な結果に対する目に見える個々の影響に部分的に依存しています。これらはすべて、他のレイヤーと同様にデータベースにも当てはまります。
- アプリケーションの動作とそのパフォーマンスを理解するには、コードとデータベースを一緒に検討する必要があります。データベースの構造またはクエリを設計するには、その使用方法を理解し、それを使用してアプリケーションを作成するには、データベースの動作を理解する必要があります。これらの事柄の知識を区分することは問題です。
- SQLの作成者と開発者の間に境界を作成することは、どちらか一方を変更することに摩擦が生じることを意味します。新しいクエリが必要ですが、既存のクエリを使用し、フェッチしすぎて、コード内で結合を行うことで、うまく実行できませんか？フィールドに外部キー制約があるか、インデックスが失われるように見えますが、コードが対応できるかどうかはわかりませんか？尋ね、説明し、待たなければならない（そしておそらく抵抗を克服する）必要のない道を進むのは魅力的です。
最初と最後の最悪のケースとして、データベースのあり方についてのビジョンを損なう（または単にもっと興味深いものから注意をそらす）ため、DBAが重要なユーザーの目に見える機能を保持することができます。あなたはずれた目標、対立、権力闘争を生み出します。
「しかし」は、チーム内の適切なスキル、テスト、コードレビュー、個々のチームメンバーの知識、設計の監視、要件の理解などが必要であることです。たとえば、誰もがデータベースのロック動作やパフォーマンス特性を理解するわけではありませんが、これを処理できるはずです。良いニュースは、とにかくコードの残りの部分でこれらすべてがすでに必要であることです。
特定のケースについては、APIとデータベース構造を高度に結合できるように聞こえます。 ORMの定義から単にパスワードハッシュ（ハッシュであることを願っています）をそのままにできないのはなぜですか？または、それをプライベートフィールドにして、「パスワードの確認」メソッドを追加しますか？または、APIを形成するためにシリアル化されるオブジェクトから除外しますか？または、返される事前定義されたAPIオブジェクトを生成する共有コードからですか？ SQLがAPIに厳密に結び付けられており、クエリを変更するとAPIが変更される場合、APIの呼び出し元を壊さずにデータベースを再構築したい場合はどうしますか？または、クライアントを書き直したり段階的にアップグレードしたりしながら、2つのバージョンのAPIが必要な場合はどうでしょうか。
ここでDBにアクセスすることは問題ではありません。開発者がAPIの不要なデータを漏らさないようにするには、公開するデータのインターフェースまたはフォーマットを定義するだけです。 APIで何を公開する必要があるかを知っている人がフォーマットを定義でき、開発者はそれを使用できません。そして、コードレビューを行って、その方法を維持するshureを作成できます。
まず、開発者のせいにしないでください。バグであっても情報が漏洩する可能性があるため、意図的に漏洩することはありません。ときどき、特に開発者がアプリケーションの小さな部分でのみ作業している場合は、変更がAPIに新しいフィールドを導入する可能性があることがわかりません。
テストを改善するをお勧めします。テストケースとスキーマの検証についてはすでに説明しました。すべてのAPI関数には、入力と出力の定義が必要です。出力は通常、特定のスキーマタイプである必要があります。これはテストできます。
たとえば、userへのクエリでパスワードが返されない場合、スキーマuserにパスワードを含めないでください。 （うまくいけばハッシュされた）パスワードを含むuser_credentialのような2番目のスキーマがあるはずです（これは悪い例です。どのような形式のパスワードも返されないようにしてください）。 APIがuserまたはuser_credentialのタイプを返す場合、優れたスキーマバリデーターは不要なプロパティをチェックでき、テストケースはチェックできます。 （ただし、これによりAPIに重大な変更が加えられる可能性があることに注意してください。）
自動チェックとテストカバレッジのメトリックを備えた最新のCIシステムを使用している場合、開発者が意図した品質レベルを超えている場合は、コミットするたびに通知することができます。
一部の業界では、サーバー間のAPI呼び出しであっても、送信できる情報の種類を制限する法律や規制が存在します。アプリケーションにどの規制フレームワークを適用するかについて、開発者がtrainingを持っていることを確認する必要があります。また、実装を開始する前に、コンプライアンスチームがシステム設計を確認する必要もあるでしょう。このようなことは、マーケティングサイトの静的テキストにも適用できます。
設計が規制の枠組みに準拠していることを確認したら、開発者が作成するものの説明にそれらの制限を含める必要があります。その後、コードレビューが不可欠になります。コードレビューのための適切なツールがあることを確認してください。
システム間のデータフローを検査し、不適切なデータ送信に自動的にフラグを立てる魔法のツールはありません。
トレーニングとプロセスの組み合わせです。
番号。
ただし、スループットよりもセキュリティおよび品質を強調できます。
会社の優先事項は何であるかについて、開発者と話します—オープンで、明確で、合理的です。開発者が快適で予測可能なペースを設定し、「仕事-生命のバランス」と会社の優先順位のために最適化します。物事が速すぎて快適ではない場合または遅すぎて興味を維持できない場合は、ユーザーに通知するように要求します。
それらを専門家のように扱います。 explicitおよびclearに、会社の期待について説明します。そして、期待のバランスが合理的であるかを交渉する余地を残してください。
そして、コーチ、サポート、グッドプラクティスと態度の奨励 —より大きく、より良い努力をするときに、彼らが持ち運ぶことができるもの：
- 「クリーンなコード」（チームはブランドを選ぶことができますが、「クリーンなコーディング」のルールを明確にし、優れた保守可能なコードに導く方法を説明できるはずです。）
- 必須のコードレビュー
- 難しい問題のためのペアプログラミング
- ユニットテスト
- 統合テスト
- 定期的な侵入テスト（おそらく内部の担当者が定期的に、外部のペンテスターが毎年から四半期に1回）
- カオステスト
- 継続的な教育と訓練
- 謙虚さ（教えるのは難しいが、非常に重要重要）
- 所有権（教えることも難しいが、投資する必要がある。）
等。
一般的に言えば、エンジニアを専門家のように扱う必要があるだけです。 （あなたが実際に採用された専門家であると仮定します。）あなたは彼らに何を求めているかについて明確かつ明確にする必要があります。そして、あなたは彼らをオープンかつ明示的に信頼する必要があります。
データのセキュリティが本当に重要な場合は、それをデザイン自体に組み込むオプションがあります。誤って機密データを誤って使用するのを防ぐためにしばらく使用した1つの解決策は、実際に機密データを次のようにSensitiveラッパーにラップすることです。
_public final class Sensitive<V> {
...
}
_map()、flatMap()などの機密データを安全に操作するメソッドを導入し、基本的にモナディックにしました。さらに、サードパーティのライブラリや画面などの「安全でない」場所に値を転送するメソッドを導入しました。これらのメソッドは目立ち、検索可能であるため、必要に応じてすべての使用を簡単に確認できます。
エンドユーザーなどの役割チェックの後でのみ値を返すメソッドを導入することもできます。
良い点は、コンパイラから助けを得るようになったことです。欠点は、機密データを処理するためにAPIを変更しなければならない可能性があることです。これはあなたが探しているものかもしれませんし、そうでないかもしれません。