問題タブ [sensitive-data]

コードをパブリックgitリポジトリに保持する場合、秘密のAPIキーやハッシュソルトなどの機密データをどのように処理しますか？

明らかに、機密データをコードに保持すると、データが危険にさらされます。

別の解決策は、秘密情報をコードにハードコーディングするのではなく、スタンドアロンファイルに保存し、ファイルをgitignoreすることです。これには、誰かが初めてコードをプルしたときに秘密情報が失われ、箱から出して実行されないという欠点があります。これは、コードに「欠落している場合は初期化」ルーチンを記述することで説明できますが、その場合、gitシステムをコードに挿入することになります。これはIMOでは適切ではありません。

また、別の解決策は、「デフォルト」の秘密情報ファイルを作成し、プロジェクトの開始時にそれをコミットしてから、コミットせずに独自の情報を使用することです。しかし、これにより、プルしたときにコミットされていない変更があるとgitが文句を言う可能性があります。

では、これを処理する一般的な方法は何ですか？

asp:GridView を使用して、asp.net、.aspx ページにデータ テーブルを表示しています。機密情報を含む列があります。ページ/グリッドビューが読み込まれたときに、このデータ列の巨大なリストが表示されないように、データをグレー表示するか、その他の方法で列を表示したいと思います。
ただし、特定の行で編集ボタンをクリックすると、列の機密データを表示して編集できるようにしたいと考えています。

これを達成する方法についてのアイデアはありますか？

Spring MVCアプリケーション内（または実際には他のJAVA Web MVCアプリケーション内）にカスタム機密データを保存するために何をアドバイスしますか？APIキーがあり、コントローラーで使用できるようにする必要があるとします。私が考えることができるいくつかの解決策：

1-静的クラスの使用：

2-コンテキストパラメータの使用（web.xml）：

3-カスタム.propertiesファイルの使用：

4-カスタム.xmlファイルの使用：

5-あなたが持つことができる他のアイデア/解決策:)

ありがとう。

非常に多くの情報を持つエンティティを構築するには、一連のフォーム送信を実行する必要があります。コントローラーからビューを返すたびに、まだ確立されていないエンティティに関する ID を渡す必要があります。現在、これらの情報を隠しフィールドに挿入し、サーバーにポストバックするときに、エンティティの構築を続けています。このシナリオは数回続きます。私は機密情報を渡すこの方法に非常に満足しておらず、他のより適切な方法があるかどうか疑問に思っていました。私は承認と認証を使用していますが、1 人のユーザーがこれらの ID をサーバーに送り返す前にハッキングし、それによって間違ったエンティティを変更する可能性があるといういくつかのシナリオを心配しています。

また、同じデータをやり取りするのは大変な作業のようです。別の種類のデータ破壊の脅威が明らかになるため、セッションの使用を失格にしました。（一度に複数のブラウザを使用する場合）。

上記の操作はどのように実行すればよいですか?

mvc では、コントローラーに送信されたときに、ユーザーが読み取り専用の隠しフォーム フィールドを悪意を持って変更していないことをどのように確認できますか?

DVCS (Github、BitBucket など) はプライベート プロジェクト コードの整合性をどのように保証しますか?

確かに、企業はあなたのコードをオンライン リポジトリにアップロードする際に知的所有権を主張していませんが、そのようなリポジトリへの書き込み/コミット アクセス権を持つ人だけが実際にデータを表示できるように、プロジェクトのプライバシーはどのように確保されているのでしょうか?

たとえば、プロジェクトをプライベート サーバーまたは別のホストに移動することにした場合はどうなりますか? あなたのプロジェクトは公開インデックスから「削除」されますか、それとも単に「削除」されますか?

プロジェクトをホストしている会社の CEO があなたのデータを閲覧できないことをどのように確認できますか?

これらの企業は何らかの定期的な認証を受けていますか? それとも、この取引全体が信頼と理解に基づいているのでしょうか?

xmlはStringBufferオブジェクトです。

私はこのコードを持っていますが、構文から機密データが漏れています response.getWriter().write(xml.toString());。私はこのことについて何の考えも持っていません。

誰でもこれについて何か教えてもらえますか? この問題は、コード監査ツールによって報告されています。

私のアプリケーションの 1 つで、ユーザー資格情報とトークンを保存します。認証情報はサードパーティ サービスで直接使用されるため、ハッシュ化できないため、そのまま保存する必要があります。

私は暗号化の専門家ではないので、Google で検索したところ、AES 256 ビット キー サイズがそのようなデータの暗号化に適していることがわかりました。

最終決定を下す前に、SO コミュニティの意見を知りたいです。

ありがとう！

編集:議論してくれてありがとう、私は今のところ暗号化メカニズムとして AES256 を使用して進んでいます。これは良い選択のようです.

シナリオは次のとおりです。アプリケーションの複数のインスタンスが（順次に）アクセスできるように、暗号化キーを一時的に保存する必要があります。もちろん、使用後はシステムからキーを削除する必要があります。ただし、これには問題があります。キーが保存されている限り、システムは脆弱であることを認めますが、キーが保存される前後のシステムを安全に保ちたいと思います。

キーをファイルに書き込んで後で上書きするだけでは、すべての場合に機能するわけではありません。一部のファイルシステムは、同じ場所ではなく、ディスクの異なる部分に変更を書き込みます。その場合でも、後でキーを取得できます。フルディスク暗号化を使用しているユーザーに頼ることはできません。

その場合、最も論理的なオプションは、キーをメモリに保持する他のプロセスを使用しているように見えますが、オペレーティングシステムが特定の時点でメモリをディスクに書き込む可能性があり、上記と同じ問題が発生します。

キーを暗号化することは可能ですが、これはより安全ではありません。キーを一時的に保存することの重要な点は、ユーザーがプログラムを実行するたびにキーを入力する必要がないことです。つまり、キーの暗号化に使用されるキーもどこかに保存するか、既知のデータに基づいている必要があります。キーが保存されている場合、もちろん、このキーを安全に保存するという問題が発生します。既知のデータに基づいている場合は、必要に応じてキーを再度生成できるため、暗号化はほとんど役に立ちません。

一部のオペレーティングシステムがデータを保護するためのAPIを提供していることは知っていますが、これは通常、ユーザーアカウント情報に基づいて暗号化キーを生成することに依存しています。これがセッション固有であっても、セッションが終了するまでデータは保護されません（キーが消去されるまでに時間がかかる場合があります）。

この問題の解決策はありますか（特別なハードウェアに依存しない、フルディスク暗号化を必要としないなど）？ない場合、この場合に私ができる最善のことは何ですか？

明確にするために編集：キーがメモリに保存されている場合、キーは安全である必要はありません。この時点で、ユーザーは物理的なアクセスが不可能であり、システムにウイルスがないことを保証する必要があります。キーを使用した後は、システムから消去する必要があります。これにより、物理的にアクセスできる人やプログラムを使用して、すべてのメモリとディスクを検査し、キーの単一の（使用可能な）トレースを見つけることができなくなります。

こんにちはみんな私は個人の機密情報の暗号化/復号化に関するセキュリティの質問があります：アイデンティティ（名前、住所、電話番号）、銀行の詳細（ソートコードと口座番号）ほとんどすべてが暗号化されており、それは本人と本人だけがアクセスできます個人データの使用を許可された人。そして今、主な質問は次のとおりです。1.私の方法は十分に安全ですか？
2.そうするためのより良い方法はありますか？
3.データベースまたは$_SESSIONのキーをどこで使用しますか？（ユーザーが詳細を確認するための復号化にキーを使用するのに最適な場所はどこですか）

コードは次のとおりです。
$iv = mcrypt_create_iv(32, MCRYPT_RAND);
$key = mcrypt_create_iv(32, MCRYPT_RAND);
$encrypted = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $unencrypted, MCRYPT_MODE_CBC, $iv);

これは、データをDBに送信する前にデータを暗号化するためのものです

$decrypted = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $encrypted, MCRYPT_MODE_CBC, $iv );

そして、これは復号化方法です（上記のサンプルの$ encode、$ key、および$ ivを使用）。