データは大企業や組織にとって新しい金であるデータは現代のほとんどの企業の生命線と見なされており、インターネットの大勢の視聴者に販売または販売する機会がたくさんあります。大手のeコマース企業やソーシャルメディア企業にとって、データは、データが厳重に保護され、オンラインでの悪意のある侵入攻撃に対する高度な保護を備えた、大きな収益と収益を生み出す能力を促進します。
つまり、金のようなデータは、処理されると貴重な状態が始まります。その生の価値は、まるでそれが巨大な分類されていないニブルであるかのように混乱に満ちています。その本質が構造化されると、データの価値は倍数になります。ユーザーが支払うことができる教育サイトがある場合を想像してみてください。ターゲットオーディエンスが学習、開発、およびある程度の生産性を獲得できる講義とモジュールがたくさんあると、必要な構造化データを取得する前に料金を調整するための扉ができるので、機会と成功の味を把握できます。 。これは誰もが成功するという夢のように聞こえますが、ビッグデータとその根底にある本質に関しては、処理するのに多くの複雑さがあり、重要な懸念はデータベースへの脅威です。
データベースの脅威には、一般に、調査および調査する必要のある多数の広範なセクターがあります。ただし、最も一般的な原因はデータの盗難とデータ侵害です。もう1つの一般的な脅威は、ユーザーに誤って割り当てられた、および/または提供されたデータベースへの広範な特権またはアクセスです。サーバーホスト全体を保護することは、データベースを管理するすべての人にとって懸念事項です。セキュリティを強化し、盗聴、改ざん、再生、サービス拒否（DDoS）など、データベースだけでなく、データストレージにアクセスできる、またはデータストレージとインターフェイスする基盤となるスタック全体に対するあらゆる種類の攻撃に対処します。
このブログでは、データベースアクセス権限を理解して持つ必要がある理由の必要性の程度について説明します。
必然的に、物理的および技術的レベルでユーザーを共有するか、少なくとも作成する必要があります。一方、他の誰かへのアクセスを提供することは、あなたがその人を信頼することを意味します。これはまた、許可された人が外界からのアクセスとデータを共有することの危険性と危険性を理解しなければならないことを意味します。
アクセス権を保護するための最も重要なポイントは、データベース管理者、セキュリティエンジニア、サーバー管理者などのエンジニア間のセキュリティに関する理解のレベルです。理解が不十分であるか、特に最新の脆弱性とエクスポージャーに関する知識と経験が不足している場合、それは組織または企業にとって問題となる可能性があります。
最小限に抑えるか、少なくとも侵入したり公開したりできないようにするために、理解して考慮しなければならない基本的なことがあります。そうしないと、データが外界から、または少なくとも間違った人に危険にさらされる可能性があります。おそらくあなたのデータを盗み、彼ら自身のためにそれを使って金銭的に利益を得るか、彼らはあなたからそれを贖い、あなたの貧弱なセキュリティ実装と引き換えにお金を要求することができます。
このセクションでは、これらのセキュリティ脅威の一般的な原因をいくつか見てみましょう。
オンプレミス環境の場合、データベース違反の通常のケースは、OSレベルまたはデータベースソフトウェアレベルのいずれかでルートアクセスを許可するという危険に主に依存しています。ルートパスワードが配布され、複数の人に公開される場合があります。これは、システムのみで作業する管理者のみに限定する必要があります。これは、アクセス権限を実装する前のプロトコルのセキュリティチェックリストまたは対策が不足しているために発生する可能性があります。セキュリティチェックリストがあると、特に特定のOSユーザーが侵入者にさらされた場合に、リスクと危険をさらす可能性のあるアクセスと特権を追跡するのに役立ちます。チェックリストは、セキュリティ対策の概要を話し合ったり、組織のプロトコルとして実装したりするのにも役立ちます。
たとえば、ルートアクセス権を持つユーザーは、物理ストレージドライブからすべてのデータを削除したり、ルートパスワードをリセットしたり、自分のユーザー/パスワードを作成したりするなど、多くの損害を与える可能性があります。正当なユーザー（早期に捕らえられない限り、データを収集するために非常に長い間使用される可能性があります）のように、postgresユーザーなどの別のOSユーザーにsudoし、侵入者が楽しむより多くの恐ろしいもの。
MongoDBを使用している場合、ルートアクセス権を持つユーザーはデータベースサーバーにログインできます。侵入者が/etc/mongod.confまたはmongodb構成ファイルを見つけてキーのパスを見つけることができる限り、ログインは簡単です。たとえば、このコマンドを使用すると、ログインできます
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"
MySQLの通常のインストール設定を検討すると、ローカルホストアクセス用のパスワードなしでルートアクセスを残すことができます。ルートになったら、簡単にアクセスできます。 $ HOME / .my.cnfなどのファイルにアクセスしたり、/ etc / my.cnfの内容を表示したりすると、簡単にアクセスできるようになります。
サーバーを直接操作してパッケージの更新、セキュリティの更新、および開発チーム。
PostgreSQL、MySQL / MariaDB、MongoDBなどの主流のオープンソースデータベースソフトウェアでは、特定のOSユーザーを作成する必要があります。 OSユーザーには、データベース機能内での機能の管理を可能にするために制限された特定のロールが必要です。基になるストレージデバイスパスに適切な読み取りおよび書き込み権限を設定する必要があります。ただし、これらの特定のユーザーをデータベースソフトウェアに使用している場合は、データベースアクセス専用に指定されたユーザーにもアクセスできるsudo特権を持っている場合があります。 OSのユーザー権限を制限する必要があり、役割に基づいてアクセスを制限するのが最善です。たとえば、Percona Server CVE-2016-6664の場合、これは修正されていますが、このタイプの脆弱性は、MySQLアカウントにアクセスしてルートアクセスを取得する特定のユーザーからの攻撃の例です。 sudoユーザーは、役割が特定の仕事をするためだけに制限されていることを確認し、理解させる必要があります。
auditdなどのLinux監査システムを有効にすると、データベースのセキュリティの脆弱性につながる可能性のあるOSレベルで見落とされたアクセス権限が発生するため、セキュリティの向上に役立ちます。 SELinuxとAppArmorは、データベースシステムをホストするLinux環境のセキュリティモジュールの良い例であり、データが危険にさらされる可能性のある侵入者や侵害に対するセキュリティを向上させるのに役立ちます。
主流のオープンソースデータベースは、特定のユーザーの特定のアクションにのみ割り当てるようにカスタマイズできる特権の詳細なリストを提供します。これは、データベース管理者が特定の特権に基づいてデータを安全に分離し、ターゲットアクションを実行できるようにするための広範な方法です。
最も一般的に使用される特権は、次の3つのカテゴリに基づくものとします。
-
SELECT、SHOW VIEW、FINDなどの読み取り/検索が可能
-
INSERT、UPDATE、DELETE、REMOVEなどの挿入/更新/削除が可能
-
CREATE USER、CREATE ROLE、ALTER、REPLICATION、DROP USER /TABLES/などの管理アクションを実行できますスキーマ、キル操作など
これらのカテゴリは、セキュリティチェックリストに基づいて、より洗練された特権に拡張できます。特定のタスクに対して特定の権限で作成される特定のユーザーを定義することをお勧めします。たとえば、アプリケーションには、独自に指定された特権が割り当てられた複数のユーザーを含めることができます。ただし、アプリケーションはこのタイプの実装と複雑になる可能性があります。たとえば、HibernateのようなORMを使用する場合など、ユーザーごとの接続がリソースを大量に消費する場合があります。一方、それはアプリケーションのアーキテクチャ設計に依存します。アプリケーションのユーザーごとのベースの目的は、より洗練されたデータベースアクセス特権を維持し、データベースを攻撃する不要な削除、更新、またはSQLインジェクションによるデータへの悪影響を回避するのに役立ちます。
ほとんどの場合、アプリケーションは1人のユーザーを使用してデータベースに接続しますが、データベースへの接続は、アプリケーションを実行するためのアクションにのみ制限されます。アプリケーションのユーザー権限を読み取り/書き込みアクセスのみに設計することをお勧めします。一方、管理アクションが必要な場合は、アプリケーションアクセス内の特定のスクリプト、デーモン、またはモジュールを通常のユーザーから分離する必要があります。
PostgreSQLとMySQL/MariaDBには、すべての権限を使用するユーザーに付与するこのオプションがあります。 PostgreSQLの場合、NOSUPERUSERを使用することも最適です。可能であれば、これは絶対に避けなければなりません。この特権は、貴重なデータを破壊または害する可能性のあるすべてのアクションのほとんどを実行できます。管理者またはルートアクセスにすべての権限を使用できますが、管理タスクを実行してデータを管理するためにスーパー権限を必要とするユーザーにのみ制限されます。
必要なテーブルに対してのみ、ユーザーにアクセスを提供することをお勧めします。 。したがって、ユーザーがいくつかの管理者権限を持っている場合でも、損傷は限られたテーブルのセットにのみ影響します。スキーマ全体に設定できます。制限されたテーブルへのアクセスを提供すると、きめ細かいタイプの特権が提供され、データを危険にさらさないようにするのに役立ちます。
リソースIPアドレスを介して接続すると、データへのアクセスを制限できます。たとえば、MySQLでは「％」を使用しないでください
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';危害の程度は、接続するホストにさらされていますが、それはあなたが望んでいたことではありません。それは脆弱性を課し、データベースに侵入するという課題は非常に低いです。
PostgreSQLの場合、pg_hba.confとユーザーをホストのみの特定の制限に設定していることを確認してください。これは、MongoDB構成ファイルまたは/etc/mongodb.confで設定できるMongoDBにも当てはまります。 MongoDBでは、認証制限を試して、clientSourceまたはserverAddressをそれぞれ設定できますが、クライアントまたはユーザーに接続または検証を要求している場合に限ります。
データベースのロールベースアクセス制御（RBAC）は、ユーザーを管理する便利な方法、またはユーザーのリストまたはユーザーのグループにリンクされた指定された特権を持つユーザーをグループ化する簡単な方法を提供します。
ただし、オープンソースデータベースでは役割の処理が異なることに注意する必要があります。たとえば、MySQLは役割を次のように定義しました。
MySQLロールは、名前付きの特権のコレクションです。ユーザーアカウントと同様に、役割には権限を付与したり、取り消したりすることができます。
ユーザーアカウントに役割を付与できます。これにより、各役割に関連付けられた特権がアカウントに付与されます。これにより、アカウントへの特権のセットの割り当てが可能になり、必要な特権の割り当てを概念化して実装するために、個々の特権を付与する代わりの便利な方法が提供されます。
MongoDBは、RBACでの役割を次のように定義しています
MongoDBは、役割ベースのアクセス制御（RBAC）を使用して、MongoDBシステムへのアクセスを管理します。ユーザーには、データベースのリソースと操作へのユーザーのアクセスを決定する1つ以上の役割が付与されます。役割の割り当て以外では、ユーザーはシステムにアクセスできません。
PostgreSQLでは
PostgreSQLは、ロールの概念を使用してデータベースアクセス許可を管理します。ロールは、ロールの設定方法に応じて、データベースユーザーまたはデータベースユーザーのグループのいずれかと考えることができます。ロールはデータベースオブジェクト（テーブルや関数など）を所有し、それらのオブジェクトに対する特権を他のロールに割り当てて、誰がどのオブジェクトにアクセスできるかを制御できます。さらに、ある役割のメンバーシップを別の役割に付与して、メンバーの役割が別の役割に割り当てられた特権を使用できるようにすることができます。
ロールの概念には、「ユーザー」と「グループ」の概念が含まれています。 8.1より前のPostgreSQLバージョンでは、ユーザーとグループは異なる種類のエンティティでしたが、現在はロールのみが存在します。どの役割も、ユーザー、グループ、またはその両方として機能できます。
これらのデータベースは、その使用法に固有の役割を実装していますが、特権を便利に割り当てるためにユーザーに役割を割り当てるという概念を共有しています。ロールを使用すると、データベース管理者は、データベースにログインまたはアクセスするために必要なユーザーを管理できます。
管理する必要のあるユーザーのリスト、または不要になったときに削除または取り消すことができるユーザーのリストがある場合を想像してみてください。特定のケースでは、特定のタスクで作業が必要な場合、データベース管理者は、すでに配置されている役割を持つユーザーを作成できます。作成されたこれらのユーザーは、特定の役割に短期間だけ割り当てられ、不要になったときに取り消すことができます。
監査は、脆弱性やデータの漏洩が疑われるユーザーを分離するのにも役立ちます。その場合、監査は、役割を持つユーザーを非常に簡単に管理するのに役立ちます。
データセキュリティが適切に処理および実装されている場合、それは成功への道を開きます。脆弱性と侵入も常に進化するため、完璧な解決策はありませんが。これは、セキュリティを侵害してデータにアクセスするという目標に到達できるまで、常に潜んでいるワームのようなものです。不安や脆弱性に対する警告システムやアドバイザリなどの適切なツールがなければ、データを保護することは困難です。
ClusterControlは、ユーザーを管理し、ロードバランサーからメインデータベースユーザーまでのユーザーの権限を確認または確認するのに役立ちます。また、脆弱性や侵入の可能性を通知するためのアドバイザーとアラートも提供します。
たとえば、MySQL / MariaDBをProxySQLで使用すると、ユーザーのインポートと追加が事前に機能します。ユーザーをインポートするために、現在のMySQL / MariaDBクラスターに存在するユーザーのリストを収集し、現在の特権を確認するように提供します。以下を参照してください
また、この場合、このような脆弱性があると、ProxySQLユーザーをすばやく非アクティブ化できます。特定のユーザーに知られています。
ClusterControlを使用すると、MySQL/MariaDBやPostgreSQLなどのデータベースからユーザーを直接管理することもできます。 MySQL / MariaDBの場合、<クラスターの選択>→管理→スキーマとユーザー
に移動できます。 
PostgreSQLの場合、<クラスターの選択>→管理→ユーザー管理。
ClusterControlを使用すると、アドバイザを使用してアラートをカスタマイズできます。アドバイザは、変更可能なスクリプトベースのエンティティです。たとえば、これは以下に示すようにMySQL / MariaDBクラスター内にあり、<クラスターの選択>→パフォーマンス→アドバイザ：
からアクセスできます。 
[編集]ボタンをクリックすると、任意のホストまたは'％"を持つユーザー、またはパスワードのないユーザーが見つかった場合のClusterControlの反応をカスタマイズできます。編集ボタン。
ClusterControlがこれらのアドバイザのいずれかがトリガーされたことを検出すると、アラートが表示され、設定した電子メールにも送信されます。サードパーティの通知が統合されている場合は、通知されます。そこにもあります。
データベースアクセス権限は、データ侵害や侵入の主な懸念事項の1つです。データベースユーザーが公開されている場合、またはパッチが適用されていない現在のデータベースバージョンに大きな脅威があった場合、ハッキングされたり、ランサムウェアや盗難の標的になる可能性が非常に高くなります。アクセス権を理解し、正しい制限を設定すると、貴重なデータを公開する危険性を軽減するのに役立ちます。