問題タブ [data-security]

次のような構造を持つ権限テーブルを使用した行レベル ACL の実装をいくつか見てきました。

Permission_Id は (読み取り、書き込み、更新、削除、承認など)

パーミッションを記述する代わりに、データとの関係 (Relationship_Id) を記述する利点があるかどうか疑問に思っていました。

ユーザーが「所有者」、「承認者」、「レビュー担当者」、「公開閲覧者」などであるという概念を説明します。

この関係は、権限のセットを定義します。これにより、アクセス許可のサイズが縮小される可能性があります。

この方法論について何か考えはありますか？

「暗号化なしの安全な通信」について疑問に思っていたところ、チャフ/ふるい分けに関する RL Rivest の論文 (およびスタックでの 2 つの後続の投稿) に出くわしました。私はアマチュア プログラマーです。そのため、「自分で作成する」などは避ける必要があります。しかし、正しい考えがあるかどうか疑問に思っています。

コードに関する簡単なメモ: 最終バージョンでは、暗号で保護されたランダム ジェネレーターが使用され (現在はテスト目的でのみ使用されます)、ストレートな sha224 ではなく sha224HMAC が使用されます。

簡単に言えば、メッセージが入力されます >> メッセージは、ランダムなソルト (公開) と共有シークレットを使用して MAC を持つ個々の文字に分解されます >> ランダムな MAC を持つランダムな数のランダムな文字が混合されます >> メッセージは圧縮されます圧縮して次の人に送る。

このシステムの問題点の 1 つは、メッセージを小さなパーツに分割する必要があるため、パーツのサイズによって情報が漏洩しないことです。私は間違っているかもしれませんが、それを圧縮して文字に分解することで、これで問題ないでしょうか?

上記のコードを実行するスクリプトからの出力のサンプル (および簡潔にするために含まれていない他のコード):

SALT: 3f441746966d9e3d269063b5c1b6c787fec25aa865365c60ce580ffd o:b3e7a01578c89fcff5d2eae4bb1d49a740f6ef935815d706d5e94417 6:16198f8ee137368cef98f469f97c2ceeca7a1f4a1ec0c01fc83521ec D:eb8532e15487c31efc39b1e381401c9d994a6b591ba00efc8089ced5 L:9d3124e8b9b5d5e15398c9413b8034dc9d46bb4b298840fcd54854de ,:1043a4ed6ec2316c4d2b71ad1cdba3d0b2cf13a213fc4ac1e9cabb78 K:79d97bfd0646ac10e4fdeddc4d7461ec57c6b7005fcfaf790525bf1f z:c30a80b64fc0cbbbcafee69ebfef67f3932e4db7ed67b03a8c2505b7 Q:37a8dae3c23364daf793c607b68a5ab5e1c9901242b96c652afb9482 p:b117f08b33519ca6ef74bd52f1c8cfb498ea6133e467e669fe7af7a3 [...]

django Web フレームワークで管理ページのデニング セキュリティ モデルを実装する手順を知りたいと思いました。このためには、サブジェクトとオブジェクトを作成する必要があります。サブジェクトはユーザーと管理者です。オブジェクトは appmodel とログ エントリです。このモデルは、ユーザーの既存の権限設定を置き換える必要があります。どうすれば簡単にプログラムできますか。

デバイス (iPad アプリ) にデータを保存できないという要件があります。を呼び出さない限り、Core Data を引き続き使用できますsave()か?

または、アプリケーションを閉じるときにコンテキストを削除して、デバイスにデータが残らないようにすることはできますか?

また、マジカルレコード（MR）を使うと違いはありますか？もしそうなら、このタイプの制約に対して Realm または MR を提案しますか?

機密データをキーチェーンに保存することは、iOS でのベスト プラクティスです。しかし、ジェイルブレイクされたデバイスを使用すると、攻撃者はすべてのキーチェーン データをダンプできます。(キーチェーンダンパー)

ジェイルブレイクされたデバイスの場合に、キーチェーン内のデータを保護する方法を理解するのを手伝ってくれる人はいますか?

公開鍵機関または公開鍵証明書から鍵に署名した場合、どうすればキャンセルできますか?

そしてここに、公開鍵機関と公開鍵証明書がどのように機能するかを示すいくつかの写真があります

すべての機密データがマスクされている画面共有アプリケーションがあります。顧客が SSN などの機密データをマスクされていないフィールドに入力するシナリオがいくつかあり、それによってソリューションが直接侵害されます。

クライアント側だけでDBやその他のサーバー側の情報にアクセスせずに、SSNや機密データを入力していることを検出できる方法はありますか?

たとえば、SSN と住所フィールドを含むフォームを考えてみましょう。アドレス フィールドに誤って入力された SSN を表示しないようにするにはどうすればよいですか?

編集

現在の私のアプローチは、すべてのパターンをクライアント側のプロパティ ファイルに格納することです。たとえば、私のアプリケーションの一般的なパスワードは 8 文字で、次のルールがあります。

この正規表現をクライアント側に保存します。ユーザーが入力を開始したら、パスワードまたはユーザー名のどちらを入力しているかを確認します。同様に、電話番号を国 - 市外局番形式に分割でき、その正規表現も使用できます。しかし、SSN は純粋な 9 桁の乱数であるため、行き詰まっています。

DOM からフィールド名を抽出することで、カーソルの正確な位置と、ユーザーがデータを入力しているフィールド名を取得できます。また、サポートされているデータ形式のタイプを使用することで、ユーザーが必要なデータを入力しているか、それ以外のデータを入力しているかを大まかに把握できます。私が間違っている場合は修正してください

9 月: 2016 年 9 月 14 日 画面共有ソリューションをブラウザーで実行しているため、Web サイトでプラグ可能なコンポーネントとして使用されるため、ページの再構築を依頼するのは簡単ではありません。以下は、あなたの入力に基づいて最終化したアプローチです。すべてのパターンが格納された 1 つのファイル ファイルを作成します。1.与信関連の情報は全て決まったパターンがあるので問題ありません 2.パスワードにもいくつかのルールやパターンがあるので、それらも確認できます

データの露出を避けるために、watsapp が「ユーザーが入力中です」と表示するように、ユーザーがデータを入力するまで一般的なメッセージを表示します。ユーザーがタブまたは次のフィールドに移動すると、インライン パターン検証後にデータのみが表示されます。

ここに残っているのは、SSN、電話番号などのパターンを持たないフィールドを検出する方法だけです。これについても何らかの解決策があることを願っています。

よろしくハリー

Rails 4.2 で実行されている API 専用サーバーには、大量のトラフィックがあります。時々、データは互いに交差します。たとえば、メーラーがメールを作成すると、間違った人にメールが送信されます。

コードを 2 回、3 回チェックしたところ、同じセッションを共有しているかのようにデータが交差していることが唯一の説明でした。それはセキュリティを危うくします。

これは Rails の既知の問題ですか? なぜこれが起こっているのか特定できません。データが危険にさらされず、独自のスレッド/セッションを排他的に実行していることを確認するための一般的なセキュリティのヒントとアドバイスをいただければ幸いです。

前もって感謝します。

私はアーキテクチャ設計のパズルを解こうとしています。それは、データとサーバーを可能な限り保護/非表示に保つためのインフラを設計することです。要件は次のとおりです。

• インフラ (パブリック ホストとプライベート ホストを備えた複数のデータ サーバー) の内部設計を隠したい

• 同じ IP アドレスを使用して各サービスにアクセスしたいのですが、クエリは何か (Cookie、URI、ポートなど) に基づいて適切なサーバーに転送されます。

• データ サービスへのアクセスには、ssl/tls 暗号化を適用する必要があります

これらの要件を注意深く検討した後、私はリバース プロキシを使用し、リバース プロキシ サーバーを介してのみすべてのデータ サービスへのアクセスを許可することを考えていました。各エンドポイントを個別に構成します。

私の本当の問題は、tcp クエリをサポートするリバース プロキシが見つからなかったことです。また、HTTP 要求に対してのみサポートされている静的負荷分散アルゴリズムについても同じです (たとえば、haproxy)。

この問題を解決する方法はありますか?

ありがとうございます