CodeGym /コース /SQL SELF /アクセス管理とセキュリティ

アクセス管理とセキュリティ

SQL SELF
レベル 47 , レッスン 0
使用可能

想像してみて、悪夢のような状況を。君はデータベース管理者で、大事な顧客データのテーブルが突然…消えちゃった!誰がやったの?なんで?もしかしたら、うっかりDROP TABLEって書いちゃった新人インターンかも。あるいは、データベースにアクセスできる悪意のあるユーザーだったかも…。何があったとしても、もう遅い!目を覚まして、気を取り直して、データベースのセキュリティについてちゃんと勉強しよう。だって、セキュリティが設定されてないデータベースは、基礎のない家みたいなもんだからさ。

データベースには、こんな脅威を防ぐためにしっかりしたセキュリティが必要だよ:

  • 不正アクセス:権限のない人がデータにアクセスしちゃう。
  • データ漏洩:パスワードやクレジットカード、機密情報が他人の手に渡る。
  • SQLインジェクション:悪意ある人が、ちゃんと守られてないクエリを使ってデータベースを操作しちゃうやつ。
  • ヒューマンエラー:うっかりデータを消しちゃったり、取り消せない変更をしちゃったり。

PostgreSQLでは、セキュリティは色んなレベルで実装されてる。ロール作成や権限管理からネットワークアクセスの制限まで。これで、誰が何をできるかを柔軟にコントロールできるんだ。

PostgreSQLの主なセキュリティレベル

PostgreSQLには、アクセス管理できる主なレベルが3つあるよ:

1. データベースレベルのアクセス管理。 このレベルでは、誰がデータベースに接続できるか、接続した後に何ができるかを決める。例えば、特定のユーザーには接続自体を禁止したり、他のユーザーには読み取りだけ許可したりできる。ここでのキーツールはロールだよ。

2. テーブル・行・カラムレベルのアクセス制御。

PostgreSQLでは、データへのアクセスをめっちゃ細かく制限できる。例えば:

  • 特定のカラムだけ読み取りを許可する。
  • テーブルのデータを、ユーザーがその行のオーナーの場合だけ読めるようにする。これはROW LEVEL SECURITY (RLS)って呼ばれてて、次のレクチャーで詳しくやるよ。
  • 重要なデータが入ってるスキーマだけアクセス制限する。

3. ネットワークアクセスの設定。 データベースは、信頼できるクライアントからのリクエストだけ受け付けるように設定できる。これはPostgreSQLのpg_hba.confっていう設定ファイルでやるんだ。このファイルで、例えばローカルマシンや特定のIPアドレスからだけ接続を許可する、みたいなことができるよ。

PostgreSQLのセキュリティツール

じゃあ、PostgreSQLがどんなセキュリティ機能を持ってて、実際どう使うのか見ていこう。

まずはロールと権限。これがアクセス管理システムの基本だよ。PostgreSQLのロールは、単なるユーザーじゃなくて、もっと柔軟なもの。1人のユーザーにも、グループにもできる。例えば、managerってロールを作って注文テーブルへのフルアクセスを持たせたり、インターンにはinternってロールで読み取りだけ許可したりできる。これなら、うっかり何か壊す心配も減るよね。

ロールはかなり細かく設定できる。誰にどんな権限を与えるか、他のロールの権限を継承できるかも決められる。誰がデータベースに接続できるか、どのスキーマやテーブルにアクセスできるか、どの行を見たり変更できるかも、全部ロールでコントロールできるんだ。

次は設定ファイル。PostgreSQLには、セキュリティに超重要な2つの設定ファイルがある。

1つ目はpg_hba.conf。これはデータベースへのネットワークアクセスを管理するファイル。誰がサーバーに接続できるか、どのIPアドレスからか、どんな認証方式を使うかをここで設定する。特定のマシンやユーザーだけにアクセスを許可したいなら、ここでやるんだ。

2つ目はpostgresql.conf。これはサーバー全体の設定ファイルで、ログや監査のパラメータもここで決める。これで、誰が何をしたかをちゃんと監視できるし、怪しい動きがあったらすぐ気付ける。

最後にログと監査。「ログは君の親友」って言うと変だけど、DB管理者にとっては鉄則だよ。PostgreSQLでは、全てのクエリやユーザーの操作をログに記録できる。何かトラブルがあった時、誰が何をしたかすぐに分かるからね。

例:SQLインジェクションからデータを守る

SQLインジェクションは、データベース攻撃の中でも超メジャーなやつ。これに対策できるのはめっちゃ大事。例えば、ユーザーが自分のアカウントIDを入力してプロフィールを見るアプリがあるとする。アプリがこんなクエリを投げてるとする:

SELECT * FROM users WHERE id = 123;

でも、もしユーザーが数字の代わりに123 OR 1=1って入力したら?クエリはこんな風になっちゃう:

SELECT * FROM users WHERE id = 123 OR 1=1;

そして、1件だけじゃなくてテーブルusersの全データが見れちゃう

どうやって守る?PostgreSQLなら、パラメータ化クエリやプリペアドステートメント(PREPAREEXECUTE)を使えば、ユーザー入力がSQLコードと混ざらないようにできる。例えばこんな感じ:

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

他にもあるリアルな脅威の例

なんでセキュリティが大事なのか、もっと実感してもらうために、リアルなシナリオを2つ紹介するね:

例1:「社員がテーブルを全部消しちゃった」

ある会社で(実はよくある話…)、インターンがうっかりコンソールでこんなコマンドを打っちゃった:

DROP TABLE employees;

そして、10年分の社員データが消滅…。どうやって防ぐ?

  • 権限管理をしっかり!例えばinternロールには読み取りだけ許可しよう。
  • 監査ログを設定しよう!誰が致命的なクエリを実行したかログで分かるよ。

例2:「暗号化されてない接続でデータ漏洩」

もしユーザーが暗号化なしでPostgreSQLサーバーに接続したら、ログインやパスワードが悪意ある人に盗まれるかも。SSLを設定して、接続がちゃんと守られてるか確認しよう。

管理者のための重要なタスク

このイントロのまとめとして、PostgreSQL管理者が絶対やるべき3つのタスクを挙げるよ:

  • アクセス制御。権限のあるユーザーだけが特定の操作をできるようにしよう。
  • 暗号化。機密データは常に暗号化して保存・送信しよう。
  • モニタリング。監査ログを設定して、怪しい動きがないか常にチェックしよう。

次のレクチャーでは、ロールの作り方、GRANTREVOKEでのアクセス管理、行レベルのアクセス制御、データ保護のための暗号化の使い方を学ぶよ。

コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION