1

私が取り組んでいるプロジェクトのポイントでは、情報が多すぎて MySQL の経験が不足しているため、物事を非常に考えすぎています。これ。" 私のアプローチ全体が愚かであり、見直されるべきであるという提案にもオープンです。このプロジェクトで交渉の余地のない唯一のものは、php と MySQL の使用です。

そこで、MySQL に行レベルのセキュリティを実装しようとしています。MySQL にはロールがないため、FGAC が必要なテーブルごとにビューを使用するか、ユーザー ID などのユーザーを特定できる情報をフィルタリングする条件を使用する必要があることを説明する良い記事を読んでください。データベースの相対的な複雑さと、データベースの性質によるセキュリティ上の懸念から、私はビュー ルートを選択しました。私が持っているビューの例を次に示します。

create OR replace view v_system_requirement (
 sys_id,
 req_id, 
 sysreq_notes,
 rate_id,
 range_id,
 art_id,
)
as
select
  system_requirement.org_id,
  organization.org_name,
  organization.org_parent_branch,
  system.sys_id,
  system.sys_name
from organization JOIN system USING (org_id)
where
  organization.org_id IN 
    (select o.org_id from organization o JOIN user u ON o.org_parent_branch=u.org_id OR o.org_id=u.org_id WHERE u.user_email=substring_index(user(), '@', 2)
);

select * from v_user_reference;

各ユーザーは独自のデータベース アカウントを持ち、大部分のユーザーは関連するビューの選択、更新、挿入などしかできないため、これにより、ユーザーが働いている組織、ユーザーの組織の直接の子組織が完璧に得られます。 、および前述の組織のいずれかに属するシステム。ユーザー名はメールアドレスであるため、ユーザー関数の substring_index の 2 であり、パスワードは十分にハッシュされています。

ここで問題が発生するのは、Web インターフェイスを追加するときです。明らかに、ユーザーがユーザー名とパスワードでログインすると、これらは mysqli_connect() を介してデータベースに渡されます。私の知る限り、ベスト プラクティスは、各トランザクションまたはトランザクション グループの実行後に接続を閉じることです。

問題は、ユーザーが自分のデータベース アカウントでどのように接続するのかということです。もちろん、毎回パスワードを再入力するように彼に求めるつもりはありません。ハッシュ化されたパスワードを $_SESSION 変数に保存するのはよくない考えですよね? それを考えると、より一般的なアカウントとして接続するためにMySQL側で実行できることはありますが、user()が実際のデータベースアカウント名を返すようにユーザーを自分自身として設定することはできますか?

それとも、冒頭で私が尋ねたように、このアプローチは単にばかげているのでしょうか? 提供できる情報をありがとう。

4

1 に答える 1