none
ダイナミックアクセス制御の利用? RRS feed

  • 質問

  • リモートデスクトップ接続しているユーザーAの個人ファイルを,同じくユーザーBの権限で一時的に読み書きさせたいです.イメージとして,アプリケーションのインストール時にのみ管理者アカウントのIDとパスを入れてインストールするようなイメージです.インストール後には管理者特権は行使できない・・・ようなイメージです.

    具体的には,ユーザーAがユーザーBとして特定のアプリケーションを実行するときに,そのユーザーBの権限で自分(ユーザーA)のファイルを読み書きできるようにしたいのです.そのアプリケーションの実行が終わるとユーザーBからはユーザーAのファイルの読み書きができないようになるのが理想です.

    素朴な方法として,runasでアプリケーションを起動し,ACLを書き換え,使用終了時にまたもとに戻すスクリプトを実行することを考えました.ただ,この時ユーザーAのファイルはかなりのファイル数があるので,その都度ACLを書き換えるのはいかがなものかと思っています.

    もう一つの方法としてダイナミックアクセス制御を利用できないかとを考えています.具体的には素朴な方法のACLの書き換え部分をADのユーザーB情報を書き換えてアクセスできるようにするものです.こうすればディスクへの負荷も小さいのかなと考えています.

    その場合リモート接続するサーバAからドメインコントローラのサーバBにアクセスしてユーザー情報を一時的に書き換える必要があると思うのですが,Windows Server 2012ではLinuxのようにコマンドプロンプトやpowershell経由でアクセスする方法があるのかちょっとわかりませんでした.きっと方法はあると思うのですが・・・・・・

    こういったケースではこうやればいい,このやり方はまずい等のコメントやご回答をお持ちの方がいらっしゃいましたら教えていただけませんか?

    2013年6月4日 14:57

回答

  • チャブーンです。

    一晩調べてみたのですが、やはり個人的にはこのようなケースでの利用はお奨めできません。

    確かに複製自体は10数秒あれば完了します(3ホップで45秒以内のため)が、そういう問題ではなく、LDAPの情報は(アクセス許可変更のために)頻繁に書き換えらえることを、基本的に想定していないためです。仮に採用するとしても、たとえば"Title(役職)"をクレームにする場合、役職を入力する本来の目的につかえません。これ専用の属性を用意する場合、スキーマの拡張が必要ですが、スキーマ拡張には知識が必要で簡単に行えず、一度行ったものを取り消すこともできません。

    ダイナミックアクセス制御では、クレームとして設定した属性が「未設定」のユーザがアクセスした場合、完全スルー(NTFSアクセス許可に依存)する仕様であり、設定を行った場合もNTFSアクセス許可との兼ね合いで思ったようにアクセスできない(あるいはできてしまう)可能性があります。現状では「補助的なアクセス許可」という立ち位置だと思います。詳しいことは、したのブログをご覧になってみてください。

    http://sophiakunii.wordpress.com/2013/01/21/ntfs%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e8%a8%b1%e5%8f%af%e3%81%a8%e3%83%80%e3%82%a4%e3%83%8a%e3%83%9f%e3%83%83%e3%82%af%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e5%88%b6%e5%be%a1/

    アクセスするファイルがどんなディレクトリ(ファイル)構成になっているかはわかりませんが、特定のフォルダ内にまとまって存在するのであれば、そのファイルを抜き出してユーザBが操作できる別フォルダに一時的に「移動」することで、瞬時にアクセス許可を変更できます。これは移動の処理がディスクデータの移動ではなくディレクトリ情報の付け替えで対応するためで、(ファイルが)アクセス権の継承する設定になっていれば、移動先フォルダのアクセス許可がそのまま反映されます。該当するファイル名やパスをテキストデータに書き、Move-Itemによる移動のためのpowershellスクリプトを作れば、実現できるのではないでしょうか。

    どうしても当初の方法でやりたいという場合も、ダイナミックアクセス制御ではなく、セキュリティグループを追加する方法が簡単(奨めませんが)のように思います。だれもメンバーになっていない新規セキュリティグループを作成し、ACL設定でユーザーBと差し替えます。必要時に、ユーザBを新規グループのメンバーに設定→runasでアプリケーションを起動→アプリケーション終了後にユーザBをグループから外す、の順番での対応が必要です。

    効果が高い別の方法として、「不慣れなユーザでも間違わない(間違いようがない)」よう、アプリケーションをカスタマイズするがあります。(設定が可能であれば)決まった動作しかできないようにUIを制限したり、自動スクリプト等で「手動操作しなくても作業が終わる」ようにするといったものです。こちらはお奨めなので、可能であれば検討してみてください。

    2013年6月6日 11:52
    モデレータ
  • チャブーンです。

    ACLを動的に書き換えたい、ということですが、NTFSアクセス許可を頻繁に書き換えた際の不備のリスクやシステム上の制約から、普通そういうことはしないように思います。またダイナミックアクセス制御を前提としたディレクトリデータの書き換えも、同じ理由に加え、リアルタイム複製はできないため認証時に問題がでるでしょう。なのでよい方法とは思えません。

    単純ですが、以下の方法ではマズイのでしょうか?

    1. 該当するすべてのファイルをユーザBが読み書き可能な別ディレクトリにコピーし、ユーザBで作業し終わったら、元の場所に再コピー
    2. (上の発展系で)同期しあう2つのディレクトリを用意し、ユーザAから見えない側のディレクトリでユーザBが作業する(自動的に同期)
    • 回答の候補に設定 佐伯玲 2013年6月10日 2:07
    • 回答としてマーク 佐伯玲 2013年6月12日 0:50
    2013年6月4日 16:59
    モデレータ

すべての返信

  • チャブーンです。

    ACLを動的に書き換えたい、ということですが、NTFSアクセス許可を頻繁に書き換えた際の不備のリスクやシステム上の制約から、普通そういうことはしないように思います。またダイナミックアクセス制御を前提としたディレクトリデータの書き換えも、同じ理由に加え、リアルタイム複製はできないため認証時に問題がでるでしょう。なのでよい方法とは思えません。

    単純ですが、以下の方法ではマズイのでしょうか?

    1. 該当するすべてのファイルをユーザBが読み書き可能な別ディレクトリにコピーし、ユーザBで作業し終わったら、元の場所に再コピー
    2. (上の発展系で)同期しあう2つのディレクトリを用意し、ユーザAから見えない側のディレクトリでユーザBが作業する(自動的に同期)
    • 回答の候補に設定 佐伯玲 2013年6月10日 2:07
    • 回答としてマーク 佐伯玲 2013年6月12日 0:50
    2013年6月4日 16:59
    モデレータ
  • チャブーン様

    ご返信ありがとうございます.

    やはり私の考えた方法は問題がありますか・・・.

    ご提案いただいた方法についてですが,該当するファイルの総数,ファイルサイズが場合によっては数百GBになるので使えるストレージサイズからすると毎回コピーするあるいは同期しあうディレクトリを設けるのは厳しいです.

    少し状況を補足させてもらいますと,ユーザーBの権限で実行するのはユーザーAだけでなくてユーザーC,D・・・・・・と複数人が実行する場合が頻度は低いのですがあり得ます.あらかじめ全員分のファイルをコピーしておくのはかなり厳しいです.

    これまではユーザーBからリモートデスクトップのユーザーA,C,D・・・の該当ファイルすべてを読み書きできるようにACLで設定していました.ところが,コンピューターに不慣れなユーザーが誤って操作してしまい,他人のファイルを破損させることが起こったので,なんとか各ユーザーのファイルを保護しつつこれまでの作業ができる環境は実現できないかと考えているところです.

    ディレクトリデータは15秒くらいの間隔で更新されると何かで読んだ気がするのですが,ごく小さいAD環境(10名弱のユーザーとサーバ3台の環境)でもディレクトリ書き換えの負荷は馬鹿にならないものでしょうか?1分くらいならウエイトを置いて待つのは運用上問題ないかなと考えています.

    2013年6月4日 17:21
  • チャブーンです。

    一晩調べてみたのですが、やはり個人的にはこのようなケースでの利用はお奨めできません。

    確かに複製自体は10数秒あれば完了します(3ホップで45秒以内のため)が、そういう問題ではなく、LDAPの情報は(アクセス許可変更のために)頻繁に書き換えらえることを、基本的に想定していないためです。仮に採用するとしても、たとえば"Title(役職)"をクレームにする場合、役職を入力する本来の目的につかえません。これ専用の属性を用意する場合、スキーマの拡張が必要ですが、スキーマ拡張には知識が必要で簡単に行えず、一度行ったものを取り消すこともできません。

    ダイナミックアクセス制御では、クレームとして設定した属性が「未設定」のユーザがアクセスした場合、完全スルー(NTFSアクセス許可に依存)する仕様であり、設定を行った場合もNTFSアクセス許可との兼ね合いで思ったようにアクセスできない(あるいはできてしまう)可能性があります。現状では「補助的なアクセス許可」という立ち位置だと思います。詳しいことは、したのブログをご覧になってみてください。

    http://sophiakunii.wordpress.com/2013/01/21/ntfs%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e8%a8%b1%e5%8f%af%e3%81%a8%e3%83%80%e3%82%a4%e3%83%8a%e3%83%9f%e3%83%83%e3%82%af%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e5%88%b6%e5%be%a1/

    アクセスするファイルがどんなディレクトリ(ファイル)構成になっているかはわかりませんが、特定のフォルダ内にまとまって存在するのであれば、そのファイルを抜き出してユーザBが操作できる別フォルダに一時的に「移動」することで、瞬時にアクセス許可を変更できます。これは移動の処理がディスクデータの移動ではなくディレクトリ情報の付け替えで対応するためで、(ファイルが)アクセス権の継承する設定になっていれば、移動先フォルダのアクセス許可がそのまま反映されます。該当するファイル名やパスをテキストデータに書き、Move-Itemによる移動のためのpowershellスクリプトを作れば、実現できるのではないでしょうか。

    どうしても当初の方法でやりたいという場合も、ダイナミックアクセス制御ではなく、セキュリティグループを追加する方法が簡単(奨めませんが)のように思います。だれもメンバーになっていない新規セキュリティグループを作成し、ACL設定でユーザーBと差し替えます。必要時に、ユーザBを新規グループのメンバーに設定→runasでアプリケーションを起動→アプリケーション終了後にユーザBをグループから外す、の順番での対応が必要です。

    効果が高い別の方法として、「不慣れなユーザでも間違わない(間違いようがない)」よう、アプリケーションをカスタマイズするがあります。(設定が可能であれば)決まった動作しかできないようにUIを制限したり、自動スクリプト等で「手動操作しなくても作業が終わる」ようにするといったものです。こちらはお奨めなので、可能であれば検討してみてください。

    2013年6月6日 11:52
    モデレータ
  • チャブーンさま

    お返事が遅くなりました.

    「アクセスするファイルがどんなディレクトリ(ファイル)構成になっているかはわかりませんが、特定のフォルダ内にまとまって存在するのであれば、そのファイルを抜き出してユーザBが操作できる別フォルダに一時的に「移動」することで、瞬時にアクセス許可を変更できます。これは移動の処理がディスクデータの移動ではなくディレクトリ情報の付け替えで対応するためで、(ファイルが)アクセス権の継承する設定になっていれば、移動先フォルダのアクセス許可がそのまま反映されます。該当するファイル名やパスをテキストデータに書き、Move-Itemによる移動のためのpowershellスクリプトを作れば、実現できるのではないでしょうか。」

    ご指摘のこの部分に関して,私の認識が不正確でした.ファイルの移動は具体的にはディレクトリ情報の付け替えしか行われていないのですね.大量にmoveすると時間もかかるしHDDにも負担をかけて壊れやすくなるかもと思っていました.この方法で対処したいと思います.

    別の方法としてアプリケーションのカスタマイズも確かに効果的だと思うのですが,設計が古い分修正を始めるとあれもこれも直す必要が出てきそうで,時間も費用も掛かりそうなので今回は上記の対処を試みることにします.どこかのタイミングでアプリケーション側の修正を試みてみようと思います.

    詳しい方のご意見をうかがうことができて,非常に助かりました.

    ありがとうございました.

    2013年6月11日 13:01