この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは。大阪オフィスの林です。
Amazon WorkSpacesを使用する際に考えなければならないことの一つとして、Amazon WorkSpacesへ接続する物理端末の管理が挙げられます。ひとことに「物理端末の管理」と言っても管理簿か何かで単純に管理すれば良いわけではありません。例えば、
- 物理端末にログインする人は誰なのか？
- アカウントは誰がどうやって管理するのか？
- 物理端末のローカルの設定をどう制御するか？
- その設定（制御）は誰がどうやってやるのか？
- 物理端末を紛失してしまった時に情報を守れるか？どうやって守るのか？ etc...
このように、一般的に考えなければならないことを挙げるだけても幾つか出てきます。今回の記事では物理端末の管理における課題に対して「G Suite」「Chrome Enterprise」「Chromeデバイス」を利用して、アカウント管理や、物理端末のローカル設定をポリシーとして一元管理しつつ、その上でAmazon WorkSpacesを使用する際に、それぞれのソリューションや機能がどのように連携しあってサービスが提供されるのかをまとめてみました。
全体の構成
シンプルに表すと下図のような構成となります。
以降で、全体の構成を3つのブロックに分けて、それぞれがどのように連携しあっているかを解説していきたいと思います。
1. Chromeデバイスへのログイン
まず、1つ目は下図赤枠のChromeデバイスへのログインです。今回はG Suiteを利用する際のほとんどのユースケースである、独自ドメインを使うケースを前提として説明したいと思います。
事前に必要な作業
G Suiteで管理されているドメインやそのドメイン配下に所属するユーザーアカウントを使ってChromeデバイスにログインできるようにするために、以下の作業が必要です。
- ドメインの所有権の証明
- Google サービス（G Suite や Cloud Identity など）で独自ドメインを利用するには、そのドメインを所有していることをGoogleに証明する必要がある。
- この証明により、他のユーザーがそのドメインを使って許可なく Google サービスを使用する（メールの送信など）ことを防止できる。
- G Suite への登録時に Google のパートナーから購入したドメインを使用する場合は、ドメインの所有権は確認済みという扱いになる。
- ユーザー登録
- 独自ドメイン配下にユーザーアカウントを作成。
- 利用者はここで作成されたアカウントを使ってChromeデバイスにログインすることができる。
- （既存ADからのアカウント同期は検証中）
- Chromeデバイス登録（オプション、推奨）
- デバイスにポリシーを割り当てるため、予めChromeデバイスを登録しておく。
管理する独自ドメインの所有権の証明と、そのドメイン配下にユーザーアカウントを登録しさえすれば、そのユーザーアカウントを使用してChromeデバイスにログインすることができます。（Chromeデバイスがインターネットに接続できることが前提）
「Chromeデバイス」と「Chrome Enterpriseデバイス」と「Chrome Enterprise Upgrade」の違い
色々と調べごとをしていると、このように似たような名前によく遭遇しましたので自分なりの解釈をまとめておきます。公式ドキュメントはこちらのページを参照ください。自分なりに内容を咀嚼して下記のように認識しました。
- ChremeOSが入ってるデバイスは「Chromeデバイス」と「Chrome Enterpriseデバイス」の2種類がある。
- 「Chromeデバイス」はデフォルトでChrome Enterpriseの機能を使えない。
- 「Chrome Enterpriseデバイス」はデフォルトでChrome Enterpriseの機能を使える。
- 「Chrome Enterprise Upgrade」はデバイスの種類ではなく、ライセンスを指す。
- 「Chromeデバイス」に「Chrome Enterprise Upgrade」を適用することでChrome Enterpriseの機能を使えるようになる。
- ライセンスはGoogle管理コンソールから適用することも可能。
2. Chrome Enterpriseのポリシー管理/適用
続いて、下図赤枠で表している部分、Chrome Enterpriseの機能を使って、ポリシーを定義・管理して適用させます。Chrome Enterpriseでは、Google 管理コンソールで利用可能な 220 種類以上のポリシーを集中管理して、ユーザー、デバイスへ適用できます。
事前に必要な作業
ユーザーアカウントやデバイスの登録は前の工程で既に完了しているため、事前に必要な作業は特にありません。ポリシーを定義していきましょう。
ポリシーの大きな分類としては、3つあります。
- ユーザーポリシー
- Chrome Enterpriseで管理されているChromeデバイスにユーザーがログインすると適用されるポリシー。
- Chromeブラウザに対してのポリシーも定義することが出来る。
- デバイスポリシー
- ユーザーが管理対象のChromeデバイス（Chromebook など）を使用する際に適用する設定を管理。
- デバイスを使用するすべてのユーザーに、デバイスレベルの設定が適用される。
- ゲストとしてログインしている場合や、個人のGmailアカウントでログインしている場合も適用対象。
- アプリケーションポリシー
- Chrome アプリ、Chrome 拡張機能、Android アプリのインストールと使用を制御するポリシー。
- アプリと拡張機能に関するポリシーを複数のアプリにまとめて適用できすることができる
- 自動でアプリをインストールしたり、ユーザーのChromeタスクバーに固定表示したりするアプリを指定することも可能。
これらの3つのポリシーを駆使してセキュリティを高めたり、社内のコンプライアンスに準拠するような設定を施し統制管理します。
3. Amazon WorkSpacesへの接続～その後
ここまでで、下地が整いましたので、Amazon WorkSpacesに接続していきます。
事前に必要な作業
Amazon WorkSpacesに接続するためにはAWS側の環境の構築はもちろんですが、接続元の端末にアプリケーションを導入しておく必要があります。ただ、この部分はChrome Enterpriseのポリシーを使ってアプリを自動で入れたりして簡略化できるでしょう。
- Amazon WorkSpacesアプリインストール
- Chrome Enterpriseのポリシーを使ってアプリを自動で入れることも可能。
- Amazon WorkSpacesの接続用アプリはAndroid/Chromebook用、またはChrome拡張機能で用意されている。
- AD作成
- Amazon WorkSpacesが認証を行う新規ADを構築または既存ADへの接続を準備する。
- （G Suiteとのアカウント同期は検証中）
G Suiteで用意されている各種グループウェアの機能もAmazon WorkSpacesから使用することができます。
まとめ
掘り下げていくとまだまだ深い機能をもったソリューション/製品ばかりなので、今後色々と触って検証していきたいと思いますが、今回は概要レベルにとどめさせていただきたいと思います。
以上、大阪オフィスの林がお送りしました！
33
