一般的なユーザーに付与する適切な権限は何ですか？[閉まっている]

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さらに限定されたセットがあります。特定のデータベースの操作に限定する必要があります。

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

一般的なユーザーは次のことを行う必要があります。

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';

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

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

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

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

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