AppStream2.0 Stacksの作成
Fleet作成完了後実施する。
Stacksはブローカリングのようなもので接続ユーザーとFleetsを関連付けるもの。
- Create Stack
- Fleets
- Name: prod-stack-001
- Display Name: Standard
- Description : 誰のために何のアプリが導入されているか記載すると親切
- Fleet はprod-fleet-001
- Next
- Home Folders⇒Enable Home Foldersのチェックを外す。これにより画面転送内でのファイル転送が不可に。
- Google Drive、OneDriveを使う場合は設定する
- Next
- ClipBoard⇒Paste to Remote Session Only これにより端末から仮想デスクトップへのみコピペ可能
- file transfer ⇒Disabled これによりファイルアップロード、ダウンロードが不可
- Print to local device⇒Disabled これにより印刷(PDF化)を不可に。
- Enable application settings persistence のチェックをオフ。 これによりアプリケーション設定の維持をしなくなる。維持したい場合はオン。
- ReviewしてCreate
- StatusがActiveなこと確認
User PoolのユーザをStackへ割り当てる
- Create User
- Email:有効なEメールアドレス
- First Name:個人名またはグループ名
- Last Name 個人名またはグループ名
- Create User押すとメール通知がされる。
- 簡易パスワードがお知らせされるのでログイン後パスワード変更 (迷惑メール入りしていないかチェックを)
- ログインを確認 (まだこの時点ではStackと関連付けていないのでApp(Chrome)は利用不可
- User Pool⇒作成したUserをチェック⇒Actions⇒Assign Stack⇒prod-stack-001→Send Email notification to user にチェックを入れておくと再度通知⇒Assign Stack
- 再度ログインして、Chromeが利用できることを確認
簡単でしたね! Ondemandを指定しているので起動に1~2分かかります。コストはかけたくないので少しは待ちましょう。利用開始時間が見えている場合はCLIで事前パワーオンしておけばよいです。
ディフォルトページをawsにしておいたのに、Chromeが強制的に元に戻しちゃっている。GPOや他の方法で設定すれば良いか。。
AppStream2.0 Fleets の作成
マスターイメージの作成完了後実施する。
Fleetsは、マスターイメージを定めたルールに基づいて起動する起動ポリシーのようなものである。
- create fleet
- Name : Prod-fleet-001
- Display Name:prod-fleet-001
- NEXT
- Imageで、prod-image-001を選ぶ Next
- stream.standard.meduimを選ぶ
- Fleet typeは ondemand ※コスト優先の場合。Always Onは常にPowerOnされているので常に課金される。
- Maximum Session duration は、960分になっているが必要に合わせて変更(Activeなセッションが維持される最大時間)
- Disconnect timeout in minutes は、15分のまま。Sessionが切断されて15分はActiveのまま残すということ。
- Idle disconnect timeout in minutesは、15分のまま。アイドル状態が15分続いたらセッションが切断されますよ、ということ。
- Fleet Capacity
- Minimum capacity は1、Maximum Capacityは5のまま ※起動する最少数と最大数を指定。
- Scaling details は、キャパシティを自動調整するルール。既定のまま。
- Next
- Default Internet Accessはチェックしない
- VPCはprod-vpc-remotework
- prod-sub-pri1 prod-sub-pri2を選ぶ
- Security Groupはdefault
- Next⇒Create⇒確認を入れてCreat
- StatusがRunningになるまで待つ
AppStream2.0 マスターイメージの作成(2)
ログイン後、アプリをインストールしていく。
- FireFoxを起動
- Google Chromeを検索してダウンロード、インストール
- デスクトップ上のGoogle Chromeアイコンをクリックして開けることを確認する。規定のブラウザに設定。
- 次にマルウェア対策製品を入れる(Defenderは有効になっているのでマルウェア対策はされているといえるので割愛しても良い)
- Image Assistantを起動
- Add Apps⇒C:\Program Files (x86)\Google\Chrome\Application⇒chrome.exeをOpen
- Add launch Settingsは規定のままSave
- Next
- CONFIGURE APPS⇒SWITCH USER⇒Template User⇒Image Assistant⇒Chrome
- Chromeの設定⇒起動時⇒特定のページ~⇒新しいページを追加⇒https://aws.amazon.com/ ⇒追加⇒Chrome閉じる⇒Chrome再度開く⇒ディフォルトページが指定のWebサイトになったこと確認⇒Chrome閉じる
- Switch User⇒Administrator⇒Save Settings
- TEST⇒Switch User ⇒Test User⇒Image Assistant⇒Chrome⇒確認
- Switch User⇒Administrator⇒Next
- Optimize⇒Chrome⇒Launch⇒Chromeが起動しきったらContinute
- CONFIGURE IMAGE
- Name:prod-image-001 ※イメージの名前
- Display Name: standard(chrome) ※コンソールに表示される分かり易い名前
- Description: Chrome ※インストールされているアプリを羅列
- Next
- Disconnect and Create Image
- セッションが切れ、イメージ作成が開始される。
- Image Builder⇒Statusがrunningになるまで待つ。
- Image Registry⇒Private⇒prod-image-001があることを確認⇒StatusがAvailableになっていればOK
AppStream2.0 マスターイメージの作成(1)
仮想デスクトップのマスターとなるイメージを作る。BaseのWindows 2019にChromeをインストールして配信する。
- Images ⇒Image Builder ⇒Launch Image Builder
- AppStream-WinServer2019-03-18-2020
- Nameに、prod-image-001
- Display Nameに、Standard
- Instance Typeに、Stream.standard.medium(2vCPU,4GB)
- VPC Endpointsは、設定しない(Amazon VPC内にある別システムなどにStreamingする場合に設定する)
- IAM Roleは、設定しない(IAM Roleを使って他AWSサービスへアクセスする際に利用する)
- Next
- Network Access
- Default Internet Accessは、チェックしない。(NATゲートウェイ経由で設定済のため)
- VPCに、prod-vpc-remotework
- Subnet1に、prod-sub-pri1
- Security Groupsに、default
- AD Domain は設定しない (仮想デスクトップを既存のADに所属する場合に利用する。いっぽうでユーザ認証はSAMLが必要。今回ユーザ認証はUser Poolとするので設定しない)
- Review⇒Launch
- Statusが、Running になるまで待つ
- prod-image-001を選択して、Connect
- Administrator選択、自動LogIn
- ログインできました
AppStream2.0 Amazon VPCの作成
Amazon AppStream2.0をリモートワークに使いたいので調べてみた。
要件はこんな感じ。
1)DaaS型で利用期間縛りなく従量課金で利用できること
2)Windows2019ベース(Defender込み)。今後クラサバ系にも使いたいので。
3)DaaS上のChromeから、社内のグループウェアやWebベースシステムにアクセス
4)ファイルのアップ、ダウンロードは禁止。コピペは仮想デスクトップ⇒端末へは禁止。印刷は禁止。
5)家のデバイスからブラウザでアクセスできること
6)画面転送の通信は暗号化されること。
仮想デスクトップを配置するプライベートネットワークとしてAmazon VPC(バーチャルプライベートクラウド)を作成します。
プライベートネットワークに配置する仮想デスクトップがNAT経由でインターネットへアクセスできるよう、NATゲートウェイ用に固定パブリックIPを用意します。
- EC2⇒Elastic IP⇒Elastic IPアドレスの割り当て⇒割り当て
仮想デスクトップを配置するプライベートネットワークとしてAmazon VPC(バーチャルプライベートクラウド)を作成します。
- サービス⇒VPC⇒VPCウィザード
- パブリックとプライベートサブネットを持つVPCを選択
- IP v4 CIDRに、10.200.0.0/16
- VPC名に、prod-vpc-remotework
- パブリックサブネットのIP v4 CIDR に、10.200.0.0/24
- アベイラビリティゾーンに、ap-northeast-1a
- パブリックサブネット名に、prod-sub-pub1
- プライベートサブネットのIPv4 CIDRに、10.200.1.0/24
- アベイラビリティゾーンに、ap-northeast-1a
- プライベートサブネット名に、prod-sub-pri1
- NATゲートウェイに、作成済のElastic IPを選択
- VPCの作成
追加で2つのサブネットを作成します。
- サービス⇒VPC⇒サブネット⇒サブネットの作成
- 名前に、prod-sub-pub2
- VPCに、prod-vpc-remotework
- アベイラビリティゾーンに、ap-northeast-1c
- IPv4 CIDRに、10.200.2.0/24
- 作成
- prod-sub-pub2を選択⇒ルートテーブル⇒ルートテーブルの関連付けの編集⇒igw-ではじまるインターネットゲートウェイがターゲットに指定されているルートテーブルを選択
- サービス⇒VPC⇒サブネット⇒サブネットの作成
- 名前に、prod-sub-pri2
- VPCに、prod-vpc-remotework
- アベイラビリティゾーンに、ap-northeast-1c
- IPv4 CIDRに、10.200.3.0/24
- 作成
次は、仮想デスクトップのマスターイメージを作る。
個人情報の取り扱い
AWSアカウント情報とカスタマーコンテンツの取り扱いについて整理しておくと良い。カスタマーコンテンツというのは、責任共有モデル における利用者が所有権を持ちコントロールする範囲のこと。(上の部分)
カスタマーコンテンツへはアクセスしないことが記載されている。
AWS では、お客様のデータをカスタマーコンテンツとアカウント情報という 2 つのカテゴリに分類しています。
カスタマーコンテンツは、お客様のアカウントに関連して AWS のサービスで処理、保存、ホストするために、お客様またはいずれかのエンドユーザーが AWS に転送したソフトウェア (マシンイメージを含む)、データ、テキスト、音声、動画、画像、ならびにお客様またはいずれかのエンドユーザーが AWS のサービスを利用して前述のコンテンツから取得した計算結果、と定義されます。例えば、お客様やいずれかのエンドユーザーが Amazon Simple Storage Service (S3) に保存したコンテンツはカスタマーコンテンツに含まれます。続く部分で説明するアカウント情報は、カスタマーコンテンツではありません。カスタマーコンテンツには、AWS カスタマーアグリーメントと AWS サービス条件の条項が適用されます。
お客様は、自分のコンテンツをすべて管理でき、AWS のサービスやリソースへのアクセス許可を設定する責任を保持します。こうした責任を効果的に実行できるように、アクセス、暗号化、ログ記録の高性能な機能セットを用意しています (例: AWS Identity and Access Management、AWS Organizations、AWS CloudTrail など)。AWS 環境で開発またはデプロイするすべてのサービスに対するアクセスコントロールの許可を設定するための API を提供しています。いかなる目的であっても、AWS はお客様の同意を得ることなく、お客様のコンテンツにアクセスしたり、それを使用したりすることはありません。マーケティングや広告のために、お客様のコンテンツを使用したり情報を抜き出したりすることはありません。
アカウント情報は、お客様がカスタマーアカウントの作成または管理に関連して AWS に提供したお客様情報と定義されます。例えば、アカウント情報にはお客様のアカウントに関連付けられた名前、ユーザー名、電話番号、メールアドレス、および請求情報が含まれます。これらの情報の取り扱い方法は、アカウント情報に適用される AWS プライバシー規約に説明されています。
https://aws.amazon.com/jp/compliance/data-privacy-faq/
オンプレミスデータセンタ要件とAWS
AWSでは、お客様のデータのセキュリティとプライバシーを保持するためデータセンターの所在地は非公表としている。(https://aws.amazon.com/jp/compliance/faq/)。パブリック・クラウドのデータセンターは複数のお客様をホストしており、お客様を含め、第三者による物理的なアクセスを最小限としている。よくオンプレミス(従来の在り方)で気になる点を確認した。
だがしかし、シンプルにISO等の認証、SOC2監査等を求めたほうが簡潔である。RFPにはオンプレミスの場合とパブリッククラウドの場合で要件を並記したほうが良い。以下の文科省から公開されている教育情報セキュリティポリシーに関するガイドライン(令和元年12月版、文部科学省)は大変に参考になる!
https://www.mext.go.jp/content/20200225-mxt_jogai02-100003157_001.pdf
データセンターの所在地は、データセンターの設置場所の国の法令が適用されるため、日本国内に限定すること。 | 場所は開示されませんが、東京リージョンは関東と言えます。東京リージョンは4つのアベイラビリティゾーン(DC群)を保有しており、大阪ローカルリージョンは1のアベイラビリティゾーンを保有しています。AWSカスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更することができます。 |
データセンターのサービスレベルは、「データセンターファシリティスタンダード」(日本データセンター協会)のTier(ティア)3相当以上に適合していること。 | AWS はUptime Institute Tier III+ ガイドラインに従ってデータセンターを運営していますが、パフォーマンスの拡大や向上に関して高い柔軟性を備えるため、認定された Uptime Institute ベースの階層化レベルを持たないようにしています。インフラストラクチャのパフォーマンスに対する AWS の手法では、Uptime Institute の階層化ガイドラインを認識し、それをグローバルデータセンターのインフラストラクチャの設計に適用することで、お客様に対する最高レベルのパフォーマンスと可用性を実現しています。次に、AWS は Uptime Institute によって提供されるガイドラインを強化してグローバルオペレーションに対応できるようスケールするとともに、可用性とパフォーマンスについて Uptime Institute の階層化ガイドライン単独で達成できるレベルをはるかに超える運用上の結果を実現します。AWS は階層 4 への準拠は主張していませんが、システムでは自己修正対策が実施され、耐障害性の高いオペレーションのシーケンスを備えていることを確約できます |
ISO27001/ISMS適合性評価の制度の認定を受けていること | AWS は ISO/IEC 27001:2013、27017:2015、および 27018:2014 への準拠の認定を受けています。これらの認定は独立した第三者監査人によって行われます。このように国際的に認められた規格および実施基準に準拠しているということは、AWS が組織のすべてのレベルで情報セキュリティに取り組んでいること、および AWS のセキュリティプログラムが業界の主なベストプラクティスに従っていることの証拠でとなります。 https://aws.amazon.com/jp/compliance/programs/ |
水害被害の恐れがない地域に立地していること。 | AWS を使用すると、各リージョン内の複数のアベイラビリティーゾーンだけでなく、複数の地理上のリージョン内に、柔 軟にインスタンスを配置してデータを保管できます。各アベイラビリティーゾーンは、障害が発生しても他のゾーンに影 響を与えないように設計されています。つまり、アベイラビリティゾーンは、代表的な都市のリージョン内で物理的に区 切られており、低リスクの氾濫原にあります(具体的な洪水帯の分類はリージョンによって異なります)。個別の無停電 電源装置(UPS)やオンサイトのバックアップジェネレータの利用に加え、単一点障害の発生をさらに減らすため、それ ぞれ別々の電力供給施設から異なる配管網を経由して電力供給を受けています。アベイラビリティゾーンはすべて、複 数の Tier-1 トランジットプロバイダに重複して接続しています。 |
サービス提供を受けるデータセンターの視察を行うため、対応可能であること。視察が認められない場合、第三者や第三者監査に類似する客観性が認められる外部委託事業者の内部監査部門による監査、検査又は国際的なセキュリティの第三者認証の取得が可能なこと。 | 立ち入り監査とは、事務所その他必要な場所に立ち入らせることにより監査目標に即した有効な監査証跡を確保することにあります。AWSのデータセンターは複数のお客様をホストしており、幅広いお客様が第三者による物理的なアクセスの対象となるため、お客様によるデータセンター訪問及び立ち入り監査は許可していません。このようなお客様のニーズを満たすために、 SOC1 Type II レポートの一環として、独立し、資格を持つ監査人が統制の有無と運用を検証しています。利用者はSOC1 Type IIレポートをダウンロード可能です。企画構想段階で、AWSとNDAを結んでいるお客様は、コピーを要求可能です。https://aws.amazon.com/jp/compliance/soc-faqs/ データセンターの立ち入り監査の実効性とは、監査の実効性は物理的な管理統制を実地で評価することにより、監査目標に対して十分な監査証跡を得ることにあります。第三者の監査レポートにより統制目標を検証することが可能であり、AWSではセキュリティの確保から物理的な統制と仮想化上の管理統制は高度に分離されておりますことから、AWSの範囲となる物理的・論理的統制の監査は、第三者の監査レポートにより統制目標を検証することが可能です。 |
避雷設備(対策)を有すること。 | また、地震・水害・避雷等の災害対策に関し、AWS データセンターは、世界のさまざまなリージョンにクラスター化されて構築されています。すべてのデータセンターはオンラインで顧客にサービスを提供しており、「コールド」状態のデータセンターは存在しません。障害時には、自動プロセスにより、影響を受けたエリアから顧客データが移動されます。重要なアプリケーションはN+1 原則でデプロイされます。そのためデータセンターの障害時でも、トラフィックが残りのサイトに負荷を分散させるのに十分な能力が存在することになります。AWS は、各リージョン内の複数のアベイラビリティーゾーンだけでなく、複数の地理的リージョン内で、インスタンスを配置してデータを保管する柔軟性をお客様に提供します。各アベイラビリティーゾーンは、独立した障害ゾーンとして設計されています。つまり、アベイラビリティーゾーンは、一般的な都市地域内で物理的に分離されており、洪水の影響が及ばないような場所にあります(洪水地域の分類はリージョンによって異なります)。個別の無停電電源装置(UPS) やオンサイトのバックアップ生成施設に加え、シングルポイントの障害の可能性を減らすために、別々の電力供給施設から異なる配管網を経由して、個別に電力供給を行っています。これらはすべて、冗長的に、複数のTier-1 プロバイダーに接続されています。顧客はAWS の使用量を計画しながら、複数のリージョンやアベイラビリティーゾーンを利用する必要があります。複数のアベイラビリティーゾーンにアプリケーションを配信することによって、自然災害やシステム障害など、ほとんどの障害モードに対して、その可用性を保つことができます |
建築に関する要件(耐震性,出入口管理,等) | AWSのデータセンターでは、最新式の革新的な建築的、工学的アプローチを採用しています。AWSは大規模データセンターの設計、構築、運用において、長年の経験を有しています。 この経験は、AWS プラットフォームとそのインフラストラクチャに活かされているものです。AWSは日本に存在するAWSサービスで利用されるデータセンターに対する地球科学的な変化のリスクを考慮し、最新式の免震装置の採用を始めとして、そのようなリスクの影響を最小限にするために真剣に取り組んできました。日本のデータセンターは日本の震災に関する規格に準拠するように設計されています(https://aws.amazon.com/jp/compliance/jp-dr-considerations/) |
また、出入口管理に関し、AWSは、業務上の正当な理由で立ち入る必要がある人々に限定して、物理的なアクセスを許可しています。データセンターへの入場を必要とする従業員とベンダーは、まずアクセスを申請し、業務上の正当性を詳しく説明する必要があります。申請は、エリア・アクセスマネージャーを含む特別に任命された人物によって審査されます。アクセスが許可された場合、必要な業務が完了した時点で、このアクセスは失効します。 入口ゲートには警備員を配置し、監視カメラで警備員と訪問者を監視する監督者も配置されています。立ち入りを許可された人はバッジを渡されます。このバッジにより、多要素認証が実行され、事前に承認されたエリアへのアクセスが制限されます。 データセンターに日常的に出入りするAWSの従業員は、職務に基づいて施設の該当するエリアへのアクセスを許可されます。ただし、彼らのアクセスも毎回綿密に検査されます。エリア・アクセスマネージャーは、スタッフリストに常に目を通し、従業員ごとに許可が必要かどうかを確認します。データセンターに立ち入る業務上のニーズのなくなった場合、従業員は一般の訪問者と同様にアクセス権限を付与するプロセスが実行される必要があります。 サイトへの未承認の立ち入りは、ビデオ監視、侵入検出、およびアクセスログ監視システムを使用して継続的に監視されています。入口はドアがこじ開けられた場合や開け放したままの場合にデバイスでアラームを鳴らすことで保護されています。https://aws.amazon.com/jp/compliance/data-center/perimeter-layer/ |
|
サーバ室に関する要件(空調設備,耐震対策,等) | AWSデータセンターは、環境を制御するとともに、サーバーやその他のハードウェアの適切な運用温度を保ち、過熱を防ぎ、サーバー停止の可能性を減らすためのメカニズムを使用しています。作業員とシステムが、温度と湿度を適切なレベルになるよう監視してコントロールしています。 また、AWSデータセンターは、自動火災検出システムおよび鎮火システムが設置されています。火災検出システムにおいては、ネットワーキングスペース、機械的スペース、インフラストラクチャースペース内で煙検出センサーが使用されています。また、これらのエリアは鎮火システムによっても保護されています。また、漏水を検出するため、水があることを検出するシステムをデータセンターに備えています。水が検出された場合、それ以上の水害を防ぐために水を除去するメカニズムが備わっています。 https://aws.amazon.com/jp/compliance/data-center/controls/#Operational_Support_Systems |
電源設備等に関する要件(受電容量,冗長性,UPS,自家発電装置,等) | AWSデータセンターの電力システムは、完全に冗長化され、運用に影響を与えることなく管理が可能となっています。1 日 24 時間体制で、年中無休で稼動しています。AWS は、施設内の重要かつ不可欠な業務に対応するために、電力障害時に運用を維持するための電力供給を可能とするバックアップ電源がデータセンターに備わっていることを保証しています。https://aws.amazon.com/jp/compliance/data-center/controls/#Operational_Support_Systems 水道、電気、通信、インターネット接続は、冗長性を持つよう設計されており、緊急時に中断しないように構築されています。電気系統は完全な冗長設計になっているため、停電の際は無停電電源装置(UPS)から特定の機能に電力が供給され、発電機から施設全体に非常用電力が供給されます。チームおよびシステムは、温度と湿度を監視して制御することで、過熱を防止し、サービス停止が起こらないようにします。https://aws.amazon.com/jp/compliance/data-center/infrastructure-layer/。 |
災害対応に関する要件(電気・水・燃料等の優先供給,等) | 日本の災害対策関連情報のサイトで、下記が記載されています。”日本のデータセンターは日本の震災に関する規格に準拠するように設計されています。AWS におけるデータセンターの事業継続性は、Amazon Infrastructure Group の指示に従って管理されています。より詳細な情報を必要とするお客様はAWSのセールス担当者、あるいはhttps://aws.amazon.com/jp/compliance/contact/ からAWSまでご連絡ください。” 追加の情報を得るにはこちらを確認すれば良さそうです。 https://aws.amazon.com/jp/compliance/jp-dr-considerations/ |