MySQL ストアドプロシージャの権限の問題の概要

MySQL ストアドプロシージャは、確かに、非常にまれな使用シナリオのように見えます。この問題は、いくつかの権限を有効にする必要のある許可申請の作業指示書を提出した開発者から発生しました。

これはごく普通の操作ですが、私の意見ではむしろ緊急かつ差し迫ったものです。正直に言うと、私は方向性の計画と開発に忙しく、この基本的な操作機能を見落としていました。そのため、現在の実装方法のいくつかを見た後でも、これらの反復的なタスクを解放するためにいくつかの小さなことをしたいと考えています。

もちろん、基本的な作業の一部は私が引き継ぐことにしました。一方では同僚の負担を軽減するため、他方では完全な体験を生み出すためでした。多くのニーズや問題点は実践を通じて簡単に把握できるからです。無理だと思うなら、このプロセスには必ず改善の余地があるでしょう。たとえば、展開とインストール、権限の有効化などです。データベース権限を有効にするのは比較的一般的なケースですが、ストアドプロシージャの権限を有効にすると、人々の生活に疑問が生じることもあります。

問題のシナリオはまだ非常に基本的です。開発者はいくつかの基本的な権限を開き、権限をマークするときに追加、削除、変更、クエリに必要な権限と、削除、変更、作成などの DDL 権限を宣言する必要があります。これを見たとき、何かおかしいと感じました。どのような操作にこのような広範な権限が必要なのでしょうか?

私は単に自分の立場を述べました。開発者の考えは管理を容易にすることだったので、私は彼を直接雇いました。簡単なコミュニケーションの後、彼らの需要シナリオは実際には非常に日常的であることがわかりました。彼らはいくつかの日常的なテーブルを動的に作成する必要があり、評価後に作成権限を付与することができました。一般ユーザーには、作成権限は推奨されません。主な出発点は、SQL の基本的な監査を実行できるようにすることです。手動監査やプラットフォーム監査も必要なプロセスです。そこで、何度かやり取りした後、有効になっている権限はすぐに削減できることがわかりました。また、特定のシナリオでは、ロジックをより柔軟に制御したいと考えているため、ストアドプロシージャのロジックを変更する必要もありました。

さて、これが基本的な背景の紹介です。基本テーブルとストアドプロシージャに権限を付与します。ストアドプロシージャに関して注意すべき重要な点は、SQL セキュリティです。デフォルトの作成は定義者です。他のユーザーに公開する必要がある場合は、呼び出し者に設定することをお勧めします。

つまり、簡単な文は次のようになります。

xxx.xxx に対する実行、変更プロシージャを xxx@'xxxx' に許可します。

残念ながら、開発者からは、SQLyog または Navicator でストアドプロシージャを開いたときにその内容が表示されないという報告がありました。

手順を選択したり、手順を表示したりする権限がないため、介入する方法はほとんどありません。

この問題は、コマンドラインを使用して再現できます。

ストアドプロシージャの実質的な内容はありません。しばらく苦労した後、それが 10 年以上前の古い問題であることがわかりました。

参考:

この問題の解決策は実は非常に簡単で、次の文だけが必要です。

mysql.proc に対する選択権限を xxxx@'xxxx' に付与します。

きめ細かい権限制御は非常に複雑ですが、確かに効果的です。

たとえば、MySQL のすべての権限は非常に大きな権限であることはわかっていますが、そこにいくつの種類の権限が含まれているかについては明確な概念がない場合があります。

きめ細かな権限制御によって、これを完全に元に戻すことができます。

たとえば、ユーザーを作成し、すべての権限を付与します。

mysql> 'jeanron100' によって識別される 'jeanron'@'%' に test.* のすべての権限を付与します。 
クエリは正常、影響を受けた行は 0 行、警告は 1 件 (0.00 秒)

含まれる権限は次のとおりです。

mysql> jeanron の権限を表示します。 
+---------------------------------------------------+ 
| jeanron@% への助成金 | 
+---------------------------------------------------+ 
| *.* の使用権限を 'jeanron'@'%' に付与 | 
| `test`.* のすべての権限を 'jeanron'@'%' に付与します | 
+---------------------------------------------------+ 
セット内の 2 行 (0.00 秒)

縮約してみましょう。

mysql> test.* への挿入を jeanron@'%' から取り消します。 
クエリは正常、影響を受けた行は 0 行 (0.00 秒) 
これで、すべての権限の許可が明らかになりました。
mysql> jeanron の権限を表示します。 
| jeanron@% への助成金 
+------------------------------------------------------------------------------------------------------ 
| *.* の使用権限を 'jeanron'@'%' に付与 
| 'jeanron'@'%' に対して、SELECT、UPDATE、DELETE、CREATE、DROP、REFERENCES、INDEX、ALTER、CREATE TEMPORARY TABLES、LOCK TABLES、EXECUTE、CREATE VIEW、SHOW VIEW、CREATE ROUTINE、ALTER ROUTINE、EVENT、TRIGGER ON の権限を 'test'.* に付与します |

したがって、上記の質問では、*.* の select に実際に必要なきめ細かい権限が既に含まれている場合、mysql.proc です。これを解明すると、基本的にはこのルーチンになります。

補足: MySQLストアドプロシージャ作成権限の問題を見てみましょう

まず、MySQL ストアドプロシージャが登場したときに、さらに 5 つのユーザー権限が追加されました。そのうち 3 つはストアドプロシージャに関連していました。

ALTER ROUTINE ストアドプロシージャを編集または削除する
CREATE ROUTINE ストアドプロシージャを作成する
EXECUTEはストアドプロシージャを実行します

これら 3 つの権限は、GRANT を使用してユーザーを作成するときに割り当てられます。デフォルトでは、ストアドプロシージャは作成者の権限で実行されます。

ユーザーがストアドプロシージャを作成する権限を持っている場合、選択、更新、または削除の権限を持っていない場合は、データを操作するためのストアドプロシージャを作成することはできますが、ストアドプロシージャを実行する権限を持っていても、ストアドプロシージャの呼び出しは失敗し、権限エラーが返されることに注意してください。したがって、誰かが、選択、更新、削除の権限がなく、CREATE ROUTINE 権限のみを持つユーザーを作成した場合は、その人を叱ってください。それは故意に行われたことだからです。

もちろん、そのようなユーザーが作成したストアドプロシージャは完全に使用できないわけではありません。ストアドプロシージャの作成には、ストアドプロシージャがランナーの権限を使用できるようにする機能句があります。ストアドプロシージャを作成したら、SQL SECURITY INVOKER 機能句を追加するだけです。

次のように。

CREATE PROCEDURE p() SQL SECURITY INVOKER 這、2 つのグループのユーザーを割り当てることができます。1 つのグループには開発者としてストアドプロシージャを作成する権限が与えられ、もう 1 つのグループにはテスターとしてストアドプロシージャを実行し、権限を選択、更新、および削除する権限が与えられます。 (頭がおかしい) このような権限の割り当てでは、MySQL のセキュリティを機能レベルで保護する必要はありません。ストアドプロシージャはルートユーザーで作成しましたが、ストアドプロシージャを実行する権限のみを持つユーザーで機能レベルで呼び出しました。したがって、機能レイヤーからデータベースのユーザー名とパスワードを取得し、IP をシミュレートしても、必要なものは何も取得できません。権限があれば、セキュリティの問題を心配することなくストアドプロシージャを使用できます。

要約する

上記は、私が紹介した MySQL ストアドプロシージャのアクセス許可の問題の概要です。お役に立てば幸いです。ご質問がある場合は、メッセージを残してください。すぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。

以下もご興味があるかもしれません: