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

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

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