この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさん、こんにちは。
AWS事業本部コンサルティング部@東京オフィスの芦沢(＠ashi_ssan)です。
主題について、このような制限をする環境を検討する機会がありましたので、検証を兼ねてブログを書いてみました。
概要とAWS構成図
同じVPC内にWorkspaces、FSx for Windowsがある環境で、Managed Microsoft ADのユーザーが所属するグループによってFSxのフォルダーに対するアクセス制限を実施します
これからやること
本検証では、Workspacesの２つのADユーザーをそれぞれ2つのADグループに所属させ、それぞれのADユーザーから起動したWorkspacesからFSxのフォルダへのアクセス制限を行います。
事前に以下のAWSリソースや情報が準備できている前提で手順が進んでいきますので、ご承知おきください。
- Directory Service(Managed Microsoft AD)
- 他ADとの信頼関係は結ばない
- Workspaces × 2
- FSx For Windows
- Directory Serviceの管理者認証情報
- Adminユーザーのパスワード
作業の流れはこちらです。
- WorkspacesからADのDNSサーバーに管理者権限で接続する
- ADグループを作成し、WorkspacesのADユーザーを所属させる
- WorkspacesのZドライブにFSxをマウントし、FSx上にGroupフォルダを作成する
- フォルダのアクセス権限を変更する(Authenticated Usersグループを削除、新規グループの追加)
- 各Workspacesからフォルダに適切な権限が付与されていることを確認する(アクセスできるフォルダとアクセスできないフォルダがある)
それではやっていきましょう。
留意事項
本エントリでは、ADに関する管理者権限を使用した操作を含めてすべてWorkspaces上で行います。
以下のようなWorkspaces上で一部のオペレーションを行えないような設定が入ってると本エントリと同様の手順を実施できません。ご留意ください。
- Directory Serviceの設定でローカル管理者権限を無効にしている場合
やってみた
AD設定(グループ作成)
まずは、任意のWorkspacesへログインします。
Active Directory ユーザーとコンピューターを、別のユーザーとして実行します。 Active Directory ユーザーとコンピューターをWorkspacesに導入してない場合、こちらのブログの手順を参考に役割と機能を使ってインストールしましょう。
Managed Misrosoft ADの管理者権限の認証情報を入力してください
※ Managed Misrosoft ADのデフォルトの管理者ユーザーはAdminです
管理者権限でActive Directory ユーザーとコンピューターを開くことができました。
管理者権限で、と記載していますが、ここでManaged Microsoft ADの制約をご紹介させてください。
Managed Microsoft ADの管理者アカウントには、ルートディレクトリ直下にあるドメインのNetBIOS名(DirectoryService作成時に指定したもの)の名前で作成されたOU配下に対してのみOUの追加削除などの編集権限を持ちます。
他のOUに関しては読み取り権限のみしか与えられておらず、AWSのみが編集権限を持っています。(参考リンク)
編集可能なOU配下にグループ用のOUを作成します。
グループ用のOUが作成できたら、その配下にグループのオブジェクトを作成します。（名前はProject1/Project2とします）
グループオブジェクト(Project1/Project2)が作成できました。
続いて、グループオブジェクトのプロパティからメンバーの追加を行います。
追加時には追加するADユーザー名の一部を入力し、名前の確認をクリックすることでADユーザーの検索ができます。
グループオブジェクト(Project1/Project2)のどちらにもメンバーの追加が完了すればOKです。
ADのグループ設定についてはここまでです。
Workspacesは次の手順でも使用するので、ログインしたままにしておきましょう。
FSxフォルダ権限設定
続いてFSxの設定をやっていきます。
まずはFSxをマウントするための設定をします。
マネジメントコンソールのFSxの画面から、マウントするFSxを選択し、アタッチをクリックします。
ファイルシステムのアタッチというポップアップが開くので、指定のアタッチ手順をWorkspacesのPowershellもしくはコマンドプロンプトで実行してください。
コマンドは正常に終了しました、と出力されたらOKです。
エクスプローラーを起動し、FSxをマウントしたドライブにアクセスします(手順通り実施するとZドライブになるはず)
アクセス制限を行うフォルダーを作成します。今回はグループ名と同じProject1/Project2を作成しました。
Project1フォルダーのプロパティ-セキュリティ-詳細設定を開いてください。
まずは既存の設定で付与されているアクセス許可エントリのプリンシパルを眺めてみましょう。以下の3つがありますね。
- Authenticated Users
- SYSTEM
- AWS Delegated FSx Administrators
Authenticated UsersはADにログオンできるユーザーすべてが所属するADグループです。
SYSTEMは文字通りシステム系の操作に関するグループだと想定できますね。
AWS Delegated FSx Administratorsはこちらのドキュメントに記載の通り、FSx For Windowsがインスタンスに接続する際に使用されるユーザーのグループのようです。
そして、今回意識するADグループは、Authenticated Usersです。
デフォルトの設定だと、フォルダーに対するアクセス権限がADにログオンできる全てのユーザーに付与されているため、想定通りフォルダー対するアクセス制御ができませんよね。
これを削除してみたいと思います。
ここでいきなりAuthenticated Usersを削除、としてしまうと以下のようなエラーが出力されます。
エラー文に記載のとおり、親からアクセス許可を継承して設定されているものなので削除が失敗したようです。
今回は親からのアクセス許可継承は不要なので、継承を解除する設定をしてみたいと思います。
先程の詳細設定画面から継承の無効化をクリックします。
このような確認画面が表示されるので、継承されたアクセス許可をこのオブジェクトの明示的なアクセス許可に変換しますをクリックします。
設定後、継承元がすべてなしとなっており、継承の無効化ができたことが確認できます。
これでAuthenticated Usersを削除できるようになったので、削除しましょう。
※ここから画像はセキュリティタブ-編集画面からのものに変わりますが、セキュリティタブ-詳細設定からでも同様の設定は可能かと思います
続いて、Project1ユーザーのアクセス許可設定を付与します。権限はフルコントロールとしています。
これで設定は一通り完了ですので、Project2の方も同様に設定を行ってください。
FSxへのアクセステスト
それでは最後にFSxのフォルダーに設定したアクセス制限ができているか確認しましょう。使用するユーザーはProject1に所属しているユーザーです。
Project1へのアクセスやファイルの作成は可能でした。
Project2へのアクセスは許可されていませんでした。
想定通り設定できていましたね。
以上、やってみたでした。
最後に
今回はWorkspacesのADユーザーを使ってFSxのフォルダーにアクセス制限をかけてみました。
一般的にWorkspacesでファイル共有というとWorkDocsを思い浮かべる方が多いかと思います。
WorkDocsはWorkspacesを利用中の方なら1ユーザー50GBまで無料で利用可能とかなりお得に使えます。
今回のようなFSxを使ったユースケースは、限られたケースかもしれませんが、どこかの誰かにいつか役に立つことができれば幸いです。
以上、AWS事業本部コンサルティング部@東京オフィスの芦沢(＠ashi_ssan)でした。
2
