web-dev-qa-db-ja.com

一般的なユーザーに付与する適切な権限は何ですか？

MySQLによって提供される特権のリスト は少し圧倒されるようです。誰がどのような特権を持つべきかわかりません。私の考えでは、私の状況には3つの一般的なユーザーがいます。

  1. root
  2. developer
  3. application

rootは自明です。 developerの場合、このユーザーは任意のデータベースに簡単にアクセスしたり、データベースに調整を加えたりできる必要があります。まず、このユーザーをこの特権セットに設定します。

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationにはさらに限定されたセットがあります。特定のデータベースの操作に限定する必要があります。

付与するのに適切な特権のセットが何かはわかりません。開発者とアプリケーションに付与するための合理的な特権セットとは何ですか？なぜですか？

mysqlsecuritypermissions
14
Avery

一般的なユーザーには次のものが必要です。

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

最初の4つは非常に明白ですが、SELECTのみを使用して「読み取り専用」ユーザーを設定することもできます。

CREATE TEMPORARYも便利で、通常は無害です。一時テーブルはクエリの最適化に役立ち、クエリをより小さくより高速な部分に分割できます。それらは実行中の接続に制限されており、閉じられると自動的にドロップされます。

EXECUTEはシステムのタイプによって異なります。ルーチンを保存しましたか？ユーザーにアクセスを許可しますか？ストアドルーチンのSECURITY=DEFINER/INVOKER定義についても確認してください。

いずれの場合も、特定のスキーマに上記のすべてを適用してください。 回避使用：

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_Host';

上記はmysqlシステムテーブルに対する権限も付与するため、すべてのユーザーが新しいアカウントを作成したり、独自の権限セットをアップグレードしたりできます。代わりに、次のようにします。

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_Host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_Host';
13
Shlomi Noach

実際の規模のシステム（つまり、個人プロジェクトではない）では、これらのユーザータイプは環境によって異なるため、それほど単純ではありません。

すべての環境で、アプリケーションには必要なものだけが必要です（通常、これは「すべてのテーブルでの選択/挿入/更新」および「すべてのプロシージャでの実行」です。異なるタスクに個別のアプリケーションユーザーがいる可能性がある大規模なシステムの場合（ 1つのアプリケーションが検閲データのフィードを担当し、別のアプリケーションがレポートを生成する責任を負います。これらの権限を分離して、必要最小限の権限を与える必要があります（レポートユーザーはおそらく権限を必要とせず、書き込み権限も持ちません）。これをテストで複製してください。テスト環境ですべてがDBにsa（MSSQLはrootに相当）としてアクセスしていたため、テストで機能するLiveに昇格したときにコードがフォールオーバーするのを見てきました。理想的には、アプリケーションユーザーは通常、スキーマを変更できる権限（CREATE、DROP、...）を持たないでください-これには例外がありますが、その数は限られています。

rootはまあ、rootです。本番環境ではこれはDBAのみであり、システムのメンテナンス（DB設計へのアップグレードなど）と監視のためだけに使用することはめったにありません。大規模なシステムの場合、特に説明責任の目的で個人を厳密に管理する必要がある規制された環境では、単一のrootユーザーをまったく許可せず、特権を小さなロールに分離することを試みないでください（私はmysqlでこれをどこまで実行できるかを確認してください。ただし、MSSQLやOracleなどでかなり細かくすることができます）。

開発者ユーザーの場合：ライブ環境へのアクセス権はまったく必要ありません。これが、アプリケーションユーザーがスキーマに影響する権限を持たない理由の1つです。開発者アカウントへのアクセス権を持つユーザーが、この方法でロックダウンを回避できる可能性があります。テスト環境でも通常はアクセス権がありません。QAにパッチを提出し、DBAは（おそらくrootユーザーを使用して）テスト環境に更新を適用します（実際、これは大規模に自動化されることが多いです）したがって、QA DBAは実際には、各サイクルのテスト環境の再構築を制御する一連のスクリプトです。開発環境では、特に開発者が実行中のサービスの独自のローカルコピーを持っている場合、これらのユーザーは、実験を行うためにすべてに完全にアクセスできる必要があります。

ただし、上記はすべての一般的な注意事項です。特定の推奨事項を作成するには、アプリケーションとその動作環境についてさらに知る必要があります。ターゲット環境は、思っているよりも重要な場合があります。ビジネス環境によっては、クライアントが診断目的で実際のデータへのアクセスを許可した場合でも、開発中であっても、ユーザーの権利は法的規制にかなり直接的に影響を与える可能性さえあります。

4
David Spillett