保険業界の実践 | 0-1からのデータベースセキュリティ基盤構築

はじめに: データベースの種類の多様化、機能の違い、クライアント間の管理と制御の効率の低さなどの課題に直面して、統合アクセス ポートをサポートするだけでなく、データのセキュリティを確保できるツールを選択する方法ソースを取得し、効率的なデータ操作を実現しますか? 国内大手保険会社が実践者として、事業背景と課題、商品選択と商品カスタマイズ、CloudQuery(以下「CQ」)利用時の課題、CQとの今後の連携計画の4つの側面から選択肢を共有します。 . プロセスと思考。

著者について: Wang Ke は現在、大手保険管理会社で DBA として勤務しており、主に PolarDB ローカライズ データベース、オープンソース データベース、データベース セキュリティ管理および制御プラットフォーム プロジェクト、およびデータベース ナレッジ運用と関連プロジェクトを担当しています。メンテナンス。

ビジネスの背景と問題点

現在の技術環境では、データの管理と処理において重大な課題に直面しています。テクノロジーの急速な発展に伴い、多種多様なデータベース製品が登場し、その種類が多いだけでなく、形式も異なり、国内データベースは1000セット以上、オープンソースデータベースは100セット以上、 Oracle や MySQL などの従来のデータベースも含まれます。これらのデータベース製品には独自の利点と特徴があり、さまざまなビジネス ニーズに対応できます。

しかし、私たちの保険業界にとって、テクノロジーの進歩は 2 つの非常に困難な問題ももたらしました。

1.統一されたデータベース操作クライアントの欠如

2. 権限管理が不十分であり、機密性の高い操作監視やセキュリティ監査が比較的不足している

統合されたデータベース操作クライアントの欠如

現在、さまざまな機能を備えた多くの種類のローカライズされたデータベース クライアントが存在します。例: PolarDB は Polar Stack を使用し、OceanBase は OCP を使用し、Dameng は独自の管理ツール インターフェイスを持ち、これらのデータベースにはより多くの著作権が含まれます。

同時に、クライアント間の管理と制御の効率は高くありません。私が現在管理している PolarDB データベースを例にとると、100 セットを超えるデータベースが 10 以上の Polar Stack クラスターに分散されています。データベース操作ごとに、対応する Stack クラスター サーバー上のデータベース アクセス IP とポートを入力する必要があります。また、10台のデータベースを運用・保守しようとすると、10個のIPやポートにログインする必要があり、異なるサーバークラスタをまたぐ必要があり、運用管理効率はあまり高くありません。

オープンソースデータベースの場合、現状のオープンソースデータベースの多くは第三者が管理するクライアントであり、第三者が管理するクライアントは企業のセキュリティ管理基準を満たすことが困難である。

権限制御

権限制御は主に、機密性の高い操作の監視と、セキュリティ監査コンテンツの相対的な不足に反映されます。

上記の 2 つの比較的難しい問題に直面すると、統合セキュリティ アクセス ポートを構築し、権限を割り当て、効率的なデータ操作を実現し、プロセス全体のセキュリティ監査を実施する必要がありますさまざまなニーズと解決する必要がある問題についてお話しましょう。

  • 統合されたセキュリティ アクセス インターフェイス >> すべてのデータは統合プラットフォームを通じてアクセスされ、社内担当者がデータベースに接続する方法が標準化され、その後の集中管理と制御が容易になります。
  • 権限の割り当て >> ユーザーの機能やアプリケーションシナリオを判断し、データベースリソースの重要性に基づいてユーザーに初期のきめ細かい権限を割り当て、高い権限の乱用による違反や情報漏洩のリスクを回避します。
  • データ運用 >> 組み込み機能が業界のアプリケーションシナリオに適合し、運用と保守の効率を向上させ、データの非感作化やデータエクスポートなどの機能を提供できることが期待されています。
  • 行動監査 >> 広範囲をカバーするフルサイクル監査であることを願っています。監査結果レポートによれば、データの実行とセキュリティの状況が要約され、内部担当者が全体的な実行のセキュリティ状況を把握するのに役立ちます。

製品の選択と製品のカスタマイズ

上記の問題点とニーズに基づいて、データベース セキュリティ管理および制御プラットフォームを選択する必要があり、市場調査を行った結果、最終的に 2 つの製品に焦点を当てました。

より多くのデータベース タイプ、特にカスタマイズされた国内データベース タイプの基準を満たすデータベースを受け入れるためには、新しいデータベースに直面するときに遭遇する可能性のある問題をサポートする安定したサービスを提供する必要があります。これらの要件に基づいて、最終的に CloudQuery を選択し、2021 年から 2022 年の最初のプロジェクト サイクルとして CloudQuery 2.3 Enterprise Edition を使用しました。

このプロジェクトに関係するデータベースの種類には、Ocenbase、PolarDB、Dameng、mongodb、mysql、redis、postgreSQL、Oracle が含まれます。クラスター形式で導入されており、社内のユーザー数は 1,000 人を超え、接続されているデータベースの数は 1,000 以上に達すると推定されます。

CloudQuery のニーズを説明した後、CloudQuery も対応するソリューションを提供してくれました。統合クライアントがないため、CloudQuery のソリューションは、プラットフォームに組み込まれた自社開発のデータベース統合操作クライアントであり、複数のデータベースを受け入れることができます

データベース操作の権限制御が難しく、機密性の高い動作を監視できないという問題に対して、データベースのユーザーと権限の一元管理を実現し、データベース操作に対する一元的な権限制御、セキュリティ監査、動作監視と警報を実施します。

権限のグローバルな制御、一意のユーザー アクセスの標準、および現在の 10 社が必要とする基盤となるデータベースのローカライゼーションのため、グローバル権限ビュー、ユーザー センター ドッキング、基盤となるデータベースなどの一部のコンテンツもカスタマイズしました。プラットフォームの一部が PolarDB に置き換えられ、動作の監視と警告、スキーマ間データの一括エクスポート...現在、この一連のコンテンツが立ち上げられ、社内の複数の部門で適用されています。

一般的に、この一連のカスタマイズ製品の発売は、国内のデータベースの統合管理と制御のニーズを満たします。同時に多数のデータベースの一元管理を実現し、管理・運用の効率化を実現します。

下の図は、上記のカスタマイズされた製品が当社でどのように使用されているかを詳しく紹介したものです。

CQ の使用時に発生した問題

私たちのプロジェクト サイクルは 2022 年に焦点を当てています。このプロジェクト中に、使用中にいくつかの問題も発生しました。問題を 3 つのカテゴリに簡単にまとめます。

1) プロジェクトの初期段階では、さまざまなデータベース ドライバーの適応、特に OBPD などのローカライズされたデータベース ドライバーの適応に問題があります。

2)さまざまなデータベースの組み込み特殊関数に対する CQ のサポート、グローバル権限ビューの設計、バッチ エクスポート機能、SQL 実行と高頻度の監視の強化などの監査ページの継続的な改善などの機能的な問題ユーザーの監視。

3) OceanBase と MongoDB の実行効率、ワークベンチ クラスターの安定性への影響、ユーザー エクスペリエンスを向上させるための OceanBase ストリーミング データベースの置き換えなどのパフォーマンスの問題

新製品は、立ち上げ初期には問題が発生することもありますが、常に生産環境に適応させる必要があり、実際のアプリケーションで遭遇する問題を乗り越えて製品を最適化することで初めて、自分に合った製品を見つけ、構築することができます。プロジェクト全体を通じて、CQ は私たちに多大なサポートを提供してくれました。その結果、CQ は安定した多様なデータベース管理と制御サポートをより適切に提供できるようになりました。

CQ 2.4 ユーザー エクスペリエンスに関する簡単な説明

7 月上旬に CQ 2.4 が正式リリースされ、私も初めて試してみましたが、その経験をお話しますと、一般的には CQ 2.4 の方が機能が豊富で、多くの点で制作業務のニーズにマッチしています。以下は簡単な例です。

  1. サポートされているデータベース タイプの観点から見ると、2.4 は GaussDB への適応を完了しており、これはバージョン 2.3 を使用するときに期待されることです。
  2. データベース操作権限の観点から見ると、CQ は「リソース管理」モジュールにスキーマ フィルタリング機能を追加しました。これにより、セキュリティ監査人は、データベースに付属するスキーマをフィルタリングできるようになります。これは、認可前のビジネス ユーザーの認可には役に立ちません。これは、より明確であり、委任の場合はより簡潔になります。
  3. 権限管理も大幅に変更されました。CQ 2.4 では、さまざまなデータベースが小さなカテゴリに分割されています。データベースの各カテゴリには N 個のデータベース リンクのサブセットがあり、このカテゴリのカスタム権限を均一に定義して権限を与えることができます。


    上の図からわかるように、権限はより詳細であり、独自の権限基準をニーズに応じてカスタマイズできます。
  4. セキュリティ管理および制御機能の観点から、バージョン 2.4 ではセキュリティ管理および制御にさらに重点が置かれています。以下の図からわかるように、データの非感作化、データ保護、監査はすべて独立した機能モジュールとして設定されており、各モジュールの機能はより豊富かつ詳細になり、セキュリティ管理の基準をより適切に満たすことができます。また、テキストのインポート、編集およびコピー可能な結果セット、元のデータベースからターゲット データベースへのデータベースのバックアップ、監査詳細の監視関連権限の表示もサポートされています。

これからの計画

下半期には新旧バージョンの入れ替えを順次完了し、バージョンが安定した後にCQと連携してデータ移行計画も策定してまいります。まずは本番環境の一部の移行が完了し、本番環境が安定したら、2.3上のすべてのデータベースリンクを置き換えて、正式に2.4に切り替える予定です。

また、引き続き機能要件の改善や使用中の新たな問題点の修正を行い、CQ と協力してプロジェクトの進捗と効率を向上させたいと考えています。最後に、CQ がより良い開発を行うことができ、強力なサポートを提供できることを願っています。より多くのユーザーのために。

おすすめ

転載: blog.csdn.net/weixin_46201409/article/details/131834461