タグ付けされた質問 「data-protection」

一般的なデータ保護規制（GDPR）は、欧州市民に関するデータの保護を改善するためのルールのセットです。このリンクからの引用： EU一般データ保護規則（GDPR）は、20年間でデータプライバシー規則の最も重要な変更です。 GDPRの主な変更点の概要、特に次のようなデータ主体の権利については、GDPRの主な変更点をご覧ください。 違反通知。 アクセス権。 忘れられる権利。 データの移植性。 デザインによるプライバシー。 ... GDPRに関するいくつかの事実： GDPRは2018年5月25日から施行されます（これはかなり近いです）。 GDPRの主要な変更からの引用（地域の範囲について）： ... EUで処理が行われるかどうかに関係なく、EUのコントローラーおよびプロセッサーによる個人データの処理に適用されます。GDPRは、EUで確立されていないコントローラーまたはプロセッサーによる、EU内のデータ主体の個人データの処理にも適用されます。ここでの活動は、以下に関するものです。EU市民への商品またはサービスの提供（支払いが必要かどうかにかかわらず） EU内で行われる行動の監視。EU市民のデータを処理する非EU企業も、EUの代表を指名する必要があります。 Y2Kを覚えるのに十分な年齢の人なら誰でも、90年代に誇大宣伝（ITシステムへの影響）を考えてみてください。これらのY2Kの問題すべてに対処するIMHOは、このGDPRの課題に比べて簡単なものでした。 質問：GDPRがDevOpsに及ぼす影響は何ですか？ GDPRに準拠させるには、DevOps ツールチェーンでどのような変更が必要ですか？ 90年代にSCMツールがY2K準拠になるのを助けたのと同様に、DevOps実践はどのようにして企業がGDPR準拠になるのを支援（促進、簡素化など）できますか？

8 toolchain  data-protection  gdpr 

私は最近、モノリシックSaaSアプリケーションをコンテナー化されたマイクロサービスに分割したい会社で働き始めました。しかし、永続ストレージの基本的な部分を把握するのに苦労しています。なぜそれほど多くの異なる競合プラットフォームがあるのですか？Portworx、Rexray、StorageOS、Flocker、Inifintなど。 私の質問 誰かが単にNFSサーバーを起動し、階層的なフォルダー構造をストレージバックエンドとして使用しないのはなぜですか？これらのツールの1つを使用すると、どのようなメリットがありますか？ Dockerでこのようなものを使用することはどれほど危険ですか？Dockerベースの環境で致命的なデータ損失の一般的な原因は何ですか？ どの永続ストレージソリューションを推奨しますか、またその理由は何ですか？私の会社はSaaSプラットフォームを運用しています。データペイロードはサイズが小さい（5kb-100kb）。データ処理は、リソース消費量が中小です。全体的なボリュームは中程度ですが、増加し続けています。モノリシックアプリケーションを個別のコンテナ化されたマイクロサービスとしてクラウドに完全に移行したいと考えています。データウェアハウスを含みます。 多少は関係ありませんが、関連しています。Rancher/ Cattleとは対照的に、Kubernetesをオーケストレーターとして使用することの利点は何ですか？中小規模のプラットフォーム用にKubernetesが過剰設計されていませんか？ワンクリックインストール以外に、ランチャーでKubernetesを使用する利点はありますか？ 洞察をありがとう。世間知らずでごめんなさい。すべてのドキュメントと補足資料を歓迎します。 編集：コンテキストでは、基盤となるクラウドプラットフォームとしてAzureを使用しています。

8 docker  kubernetes  storage  data  data-protection 

高度に規制された環境での作業データは、感度に応じてさまざまな方法で分類されます。場合によっては、これは法的に強制され、別の扱いが必要になります。 データ分類ポリシーの例は次のとおりです。 パスワード、秘密鍵、SAMLトークン、クレジットカード番号などの非常に制限されたデータ。 ユーザー名やお客様IDなどの制限されたデータ。 無制限のデータ、ほとんど何でも。 この分類には特定の義務が伴います。 厳しく制限されているデータは、いかなる状況でもログファイルで利用可能にしてはなりません。 特定の条件下では、制限されたデータがログファイルで利用可能になる可能性があります。たとえば、サービスでインシデントが発生した場合、オンコールエンジニアはBreak-Glass手順を実行して、このデータにアクセスして問題を診断できます。次に、Break-Glass手順により、レビュー、監査、および場合によってはそのエンジニアからの一時的な特権の取り消しがトリガーされます。 これを達成するためにどのような戦略を採用することができますか？特に、この問題に直接的な回答を提供しない、幅広いロギング、モニタリング、および計測ツールが市場に出回っていることを考えると？ たとえば、SplunkとAppDynamicsのどちらにも、公開されているテレメトリの条件に応じて異なるアクセス制御を課すことができます。つまり、マスクするフィルターを作成できます<customerId>NNNNNNNNNNNN</customerId>。ただし、これらのツールはどちらも、クレジットカード番号を自動的に識別して自動的にマスクする機能を提供しません。 注：これはDevOpsに関連していると思います。これは、従来の階層型サポートモデルでは、比較的少数のグループがデータにアクセスして手動でフィルタリングできるため、オペレーティングチームの責任を開発チームに委譲することにより、このデータが遠くにさらされる可能性があるためです。より広い聴衆。

7 security  logging  data  financial-services  data-protection