みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
使用環境:FileMakerServer19.0.1、FileMaker19.3.2
現在、分離モデルでカスタムAppを作成しています。
ファイルの構成は、UIファイルが1つ、MasterファイルやDataファイル等が3~5つになる予定です。
ファイルへアクセスするためのアカウントは各ファイル自体が持つFileMaker標準のセキュリティを活用しようと思っています。
各ファイル毎にユーザー数分のアカウント、パスワードを登録して運用する予定です。
その前提のもとで、
ユーザーの初回アクセス時や、パスワード期限が切れていた場合に、パスワードを変更してからログインしてもらうようにしたいのですが、ユーザーがUIファイルのパスワードを変更したタイミングで、他関連ファイルのパスワードを同様に変更するにはどうすればよいか悩んでいます。
パスワードの変更ダイアログをファイル標準のダイアログで運用しようと思うと、全てのファイルに対して一つずつパスワードの変更が必要になってしまいます。
そこで次のように考えました。
新規ユーザー作成時に、パスワード期限の情報をユーザーマスタテーブルに持たせる
→起動時にパスワード期限を確認
→期限が切れていたらカスタムダイアログでパスワードを変数で取得
→全てのファイルでパスワードを変更
→パスワード期限を更新
上記であればユーザーは1回のパスワード更新で済む気がしますが、出来ればパスワード関連の情報は(パスワード期限のみとはいえ)あまりテーブルに保存しておきたくないと思い、パスワードに関する情報は全て標準のセキュリティ機能のみで実現できないものかと悩んでおります。
以下の条件をクリアする何か良い方法はありますでしょうか。
・FileMaker標準のユーザーアカウント機能を使う
・パスワードに有効期限を持たせる
・有効期限も含めパスワードに関する情報はテーブルに保存しない
・分離モデルで構成する
・ユーザーは1回のパスワード変更で、全てのファイルのパスワードが更新される
何卒よろしくお願い致します。
Offline
> 出来ればパスワード関連の情報は(パスワード期限のみとはいえ)あまりテーブルに保存しておきたくないと思い、パスワードに関する情報は全て標準のセキュリティ機能のみで実現できないものかと悩んでおります。
可能ですよ。
アカウント名は、氏名と同じレベルのものですから、保存しても問題ないでしょう。
パスワードそのものはレコードに保存せず、設定してあるパスワードのハッシュ値を保存することで、入力されたパスワードの真偽を確認できます。ハッシュ値でしたら保存してもなんら問題ないでしょう。
有効期限を保存しないのでしたら、FMのパスワード期限を使えばいいと思いますが、ユーザーからは、メインのファイルも見えてしまうはずですが、それらのファイルでもFMの機能でのパスワードの期限を利用することになりますので、期限が切れた後でのパスワードの変更は、ファイルごとに行わないといけなくなります。それを回避するにはカスタムダイアログでアカウント名とパスワードの変数へ取得しておき、別の準管理者アカウントでログインし直し、各ファイルのパスワードを変更し、再ログインしておく、という面倒な動きを作る必要が出てきます。ですから、単にアカウントの管理テーブルで期限を管理しておいた方が楽でしょうね。
Offline
Shin様
早速の返信ありがとうございます!
FMアカウントが持つパスワード有効期限を使って複数ファイルを管理するのは手間がかかりそうですね。
アドバイスいただいた通り、パスワード期限を管理テーブルに保存する方針で考えていこうと思います。
考えているうちに、ユーザーアカウント情報はパスワードのハッシュ値や有効期限などを全て管理テーブルに保存して、FMアカウントはアクセス権ごとに1つづつ用意するだけで良いかも、と思いました。
ただその場合、FMアカウントのパスワードをどのように保存しておくのかという問題や、レコードの更新者情報などをアカウント名で取得している場合は、別の仕組みが必要になってしまうという事も気づきました。
レコードの更新者情報は各ファイルにユーザー名のグローバルフィールドを用意しておけば解決出来そうですが、FMアカウントのパスワードをどう保存しておけばよいかは思いつきませんでした。
今回初めて複数名が使用するシステムを作ろうとしているため、セキュリティの設計は想像以上に大変なんだなと実感しました。
運用を開始してからセキュリティの仕組みを変えるのは大変そうなので、しっかり検討してみようと思います。
アドバイスありがとうございました!
Offline
> FMアカウントはアクセス権ごとに1つづつ用意するだけで良いかも
これは、お薦めしません。アカウントは、必ず個人と一致させるべきです。そうしないと、パスワードの管理が不可能ですし、データ内容の信憑性がなくなります。
> レコードの更新者情報は各ファイルにユーザー名のグローバルフィールドを用意しておけば解決出来そうですが、
おそらく無理な運用になると思います。
> FMアカウントのパスワードをどう保存しておけばよいかは思いつきませんでした。
パスワードを平文で保存するしかなくなりますよ。暗号化してもいいでしょうが、暗号化のキーをスクリプトかどこかのテーブルに保存して復号する必要が出てきますので、それを取得できれば暗号の意味がないでしょう。
Offline
Shin様
ありがとうございます。
ユーザーごとにFMアカウントを作成するようにします。
次のようなフローでテストしてみようと思います。
セキュリティ上の問題はありそうでしょうか。
1.アクセス権セットの準備
管理ユーザー(データ入力のみと同等の権限+完全アクセスのないアカウントを管理の有効化)
一般ユーザー(データ入力のみと同等の権限+ユーザーによるパスワードの変更を許可の無効化)
2.ユーザー管理テーブルの準備
フィールド:ユーザー名(FMアカウント名と同一、ユニーク)、パスワード有効期限
3.新規ユーザー登録
パスワード期限なしの一般ユーザー権限アカウントを各ファイルに登録(管理ユーザーがスクリプトで行う)
同時にユーザー管理テーブルのレコードに、ユーザー名、パスワード有効期限(期限切れの状態)を保存
3.ユーザーがログインした際のスクリプト
パスワード有効期限をチェック、期限が切れていたらカスタムダイアログで新パスワードを入力してもらう
パスワードの要件を満たしているかチェック、OKなら入力された新パスワードを変数に保存
変数として保存されたパスワードで全てのファイルに対してパスワード変更のスクリプトを実行(管理者権限で実行)
パスワード有効期限を更新(管理者権限で実行)
Offline
カスタムダイアログで、直接変数の設定ができますよ。
翹向内陽画わからないですが、入力のみでいいのでしょうかね。
Offline
Shin様
ありがとうございます。
カスタムダイアログで直接変数で取得、これは便利ですね。
早速活用しようと思います。
業務内容は自社食品製造業のスタッフ管理および生産管理を行う予定です。
管理ユーザーは、スタッフの登録、シフトの調整、商品マスタの登録、業務データをchatworkに送信、などを行います。
一般ユーザーは、日々の業務実績データや、画像などの登録をします。
管理ユーザーであっても、レイアウト編集、スクリプト編集は行わない予定です。
値一覧の編集はOKとするかもしれません。
管理ユーザー、一般ユーザーともに、基本的には全てのテーブルでのレコード操作(読取り、作成、編集、削除)と、スクリプトの実行のみ権限があれば問題ないかと思っていましたが、今のところ起こりうるトラブルが想像できていない、というのが現状です。
情報が少ないかもしれませんが、何かお気づきの点があればご助言いただけると助かります。
Offline
Pages: 1
[ Generated in 0.007 seconds, 10 queries executed - Memory usage: 540.04 KiB (Peak: 560.58 KiB) ]