blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2019.09.07 DeNAインフラノウハウ発信プロジェクト

社内システムのクラウド移行

by Keishiro Tamura

#infrastructure #infosys #windows #AmazonWorkSpaces #cloud-migration #iaas #paas #saas #infosys-infrastructure #infra-quality #infra-delivery

こんにちは、IT基盤部の田村です。
社内システムのインフラを担当しています。

我々が管理・運用しているシステムは、先月、エンジニアブログでジュンヤさんの記事にもあった通り、Windows、Linux、アプライアンスなど様々なOS、ミドルウェア、ハードウェアを使用していますので、クラウドへ移行するのも同様に様々なパターンがあります。そのため、オンプレミスと同じような構成で移行できるのか、はたまた、AWS上のサービスを利用出来るのか、模索しながら移行を進めています。

現在、社内システムは、本番環境と開発環境、合わせて300台ほどあります。これらを2019年度末までにクラウドへ移行する予定です。

※2019年9月現在の進捗状況

Windowsのシステムを先行して移行していますが、その中から、アプリケーション(WindowsServer2012R2)+コンソールPC(Windows7)のシステム構成をどのように移行したか書きたいと思います。

オンプレミスの構成と利用方法

本番セグメントのサーバーにログインするには、セキュリティー上、必ずゲートウェイサーバーにリモートデスクトップで接続し、そこから本番サーバーに接続するルールになっています。ゲートウェイサーバーでは、ユーザーが何をやったか後から追えるよう、証跡を取っています。
このアプリの担当者は、ゲートウェイを経由してコンソールPCに接続後、コンソールアプリを起動して業務を行います。 コンソールPCはWindows7なので、1台1人しかログインできません。 担当者は十数名いるので、利用時は声を掛け合って利用してます。

まずはAWSにインスタンスを立ててみよう!

練習がてら、Windowsのインスタンスを立ててみます。
すると、いきなり問題発生!

Amazon Machine Image(AMI)にWindows7がない!
Windows10もない!!

これは困りました。
WindowsServer2012R2で立てるしかないのか。。。と諦めかけたとき、救世主登場!
Amazon WorkSpaces というセキュアなクラウドベースのデスクトップサービスがありました。

Amazon WorkSpacesを使ってみる!

これは使えるかも?ということで、WorkSpacesにインスタンスを立ててみます。

OSは、Windows7か10、またはAmazon Linux2から選べます。
Windows7のEOSは2020年1月14日なので、Windows10を選択します。

料金体系は、月額料金と時間料金のいずれかを選択できます。
今回構築するコンソールPCはそれほどスペックはいらないので、Windowsバンドルのバリューを選択することにします。

OS バンドル 月額料金 時間料金
Windows バリュー 34USD 10 USD/月 + 0.30 USD/時間

利用時間が月80時間を超えるようであれば月額料金がお得です。
ただ、時間料金だとアクティブではなくなってから指定された期間が経過した後に自動的に停止しますので、起動に時間がかかります。

15分ほどで構築が完了し、実際接続してみます。
自分のPC(MacBook Air)に 接続アプリ をインストールして直接繋ぐ???
なるほどー、こうやって使うのか!と感心してたのもつかの間、またもや問題発生しました!

  • WorkSpacesを作成したときのアカウントでしか接続出来ない。1つのWorkSpaceに対して最大20ユーザーまで登録が可能だが、ADと連携している場合、1アカウントあたり1つのWorkSpaceとなり、1アカウントで複数台に接続設定をすることが出来ない。
    つまり、担当部署全員を全てのWorkSpacesに権限を付与することが出来ません。
  • 証跡が取れないので、担当者が悪いことをしてもバレない
  • どこからでも接続出来る?

3つ目の「どこからでも接続出来る?」の問題は、WorkSpacesの管理画面にIPアクセスコントロールの設定がありましたので、オフィスのOutbound IPを設定すれば制限出来ました。 しかし、それ以外は仕様上解決出来そうにありません。

根本的に構成を見直し

接続ツールは諦め、IDCとAWSが専用線で接続されているので、IDC経由でコンソールPCに接続出来ないか検証します。
結論を先に述べさせていただくと、全ての問題を解決した理想通りの構成となります!

やりたかったことをおさらい

  • ゲートウェイ経由でアクセスし証跡を取る
  • 個人アカウントで全てのコンソールPCにログイン出来るようにする
  • 接続アプリ経由ではアクセスさせない
  • アクセス元制限をかける

事前に用意するもの

  • WorkSpacesを作成する際に必要なアカウントをActiveDirectoryのUserに必要台数分登録する。
  • AWS Direct Connect または AWS VPN でIDCとクラウド間を接続する。
  • AD Connector を設定し、ADからユーザー情報が引けるようにする。

構成図

実際に構築していきます!

  1. Amazon WorkSpacesコンソールを開きます。
  2. WorkSpacesの起動をクリックします。
  3. 「ディレクトリの選択」
    作成済みのAD Connectorを選択します。
  4. 「ユーザーの特定」
    追加するユーザーは、事前に用意するものに書いてあるWorkSpaces作成用のアカウントです。
  5. 「バンドルの選択」
    使用したいバンドルを選択し、ボリュームサイズを指定するのですが、このユーザーは初期設定時しか使わないので、ユーザーボリュームは最小限(10GB)にしてください。ルートボリュームも後から増やせるので最小の80GBで設定します。
  6. 「WorkSpacesの設定」
    実行モード、暗号化、タグの管理は用途に合わせて設定します。
  7. 内容を確認してWorkSpacesを起動します。
  8. プロビジョンが完了するとログイン手順などが書かれたメールが届きますが、この情報は担当部署には共有しません。
  9. IPアドレスは固定にしたいので、Elastic IPを設定しておきます。
  10. このIPアドレスをDNSに登録しておくと、リモートデスクトップで接続する際便利です。
  11. WorkSpacesのIPアクセスコントロールの設定のところは、OfficeのOutboundIPを設定しておきますが、接続アプリでは接続させたくないので、リモートデスクトップで接続出来るようになったら削除します。

リモートデスクトップで接続

WorkSpacesのセキュリティグループの設定を行い、RDP接続が出来るようにします。

  1. Amazon WorkSpacesコンソールを開きます。
  2. 接続したいWorkSpaceの詳細を表示し、[WorkSpace IP] のIPアドレスをクリップボードにコピーします。
  3. Amazon EC2コンソールを開きます。
  4. ナビゲーションペインの [ネットワークインターフェイス] をクリックします。
  5. 検索ボックスに、先程のIPアドレスをペーストし対象を絞り込みます。
  6. 詳細の[セキュリティグループ]に表示されているリンクをクリックします。複数表示されたら設定したい方を名前をクリックします。
  7. [インバウンド] タブを選択して、[編集] をクリックします。
  8. [ルール追加]で下記を追加します。
    タイプ:RDP
    プロトコル:TCP
    ポート:3389
    ソース:今回はゲートウェイサーバーからのみアクセスさせたいので、そのIPアドレスを入力します。
    説明:allow rdp
  9. [保存]をクリックします。

※参考資料
AWS Knowledge center 「 どうすれば、RDP を使用して WorkSpace に接続できるのでしようか?

Windows10の接続権限設定

Windowsに、WorkSpacesの接続ユーザー以外でもログイン出来るようにします。

  1. 接続アプリを使用して、WorkSpacesに接続します。
  2. コンピュータの管理 - ローカルユーザーとグループを開きます。
  3. グループ内のAdministratorsにアクセスさせたいユーザーが属するグループを設定します。

これで設定完了です。
担当部署全員が、ゲートウェイサーバーを経由して、使いたいコンソールPCにログイン出来るようになりました。証跡もバッチリ取られています。

特記事項

  • DドライブにはUserProfileに割り当てられています。この領域はWorkSpaces作成時「ユーザーの特定」で設定したユーザーのみしか使えないため、今回は利用しません。ユーザーボリュームを最小限で作成したのはそういった理由です。
  • 「ユーザーの特定」で登録していないユーザーでログインすると、C:\Users以下にプロファイルが作成されます。(通常のWindowsと同じ)
  • エクスプローラを開いたとき、Cドライブは見えないため、窓にC:\と入力して開く必要があります。
  • ルートディレクトリは定期バックアップ対象ではありませんので、基本的にローカルにデータは置かないほうがいいです。

最後に

Windowsのアプリケーション(WindowsServer2012R2)+コンソールPC(Windows10)のシステムをAWSに立てるというのは、極稀れかも知れませんが、社内ではこの構成が2種類ありますので、きっと需要はあるはずです。そのような方に参考になれば幸いです。

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。