AWS環境でのシステム構築の際に各サーバのベースとなるWindows2016サーバテンプレートを作成した時のメモ。
ドメイン参加はテンプレートを使って各サーバを構築した後にそれぞれのサーバで実行する方針。
IAMロール作成
-
IAMはテンプレートから展開される各サーバに割り当てる事になるのでサーバの役割・用途に応じて作り分けるとよい。
- 1 つの EC2 インスタンスに同時に関連付けることができるのは 1 つの IAM ロールのみです。インスタンスあたり 1 つというロールの制限を増やすことはできません。
https://aws.amazon.com/jp/iam/faqs/
- 1 つの EC2 インスタンスに同時に関連付けることができるのは 1 つの IAM ロールのみです。インスタンスあたり 1 つというロールの制限を増やすことはできません。
-
とりあえず汎用のIAMロールとして下記の権限でIAMロールを作成
用途 | ポリシー | 備考 |
---|---|---|
Systems Manager | AmazonSSMManagedInstanceCore | Systems Manager(SSM)でEC2タスクを実行する為の権限。 SSMでのCloudWatchAgentインストール時にも必要。 |
CloudWatch Agent | CloudWatchAgentServerPolicy |
- SSM用権限は従来AmazonEC2RoleforSSM を使用してきたが、権限が広すぎる為将来的に非推奨になるとの事
Developers.IO | 新ポリシー AmazonSSMManagedInstanceCore がサポートされました
EC2インスタンス作成
Windows 2016日本語版のAMIでインスタンスを作成
- インスタンスイメージ選択画面のクイックスタートには英語版のWindowsサーバのみなので下記を参考に日本語版AMIを選択してインスタンスを作成
Administratorユーザのパスワードを取得
- AWSコンソールから作成したインスタンスのAdministratorユーザのパスワードを取得
OS初期セットアップ
セキュリティ強化設定や不要サービスの停止、こまごました動作設定を行う。
詳細はこちらに記載。
- Windows 2016 OSインストール時にやる事リスト
- タイムゾーン設定はSysprepを実行したタイミングで元に戻ってしまうようなのでサーバ複製後に再設定が必要。
AWS関連設定
IMDSv1の無効化
- IMDS(Instance Meta Data Service)はIAMロールによるアクセスの際に使用されるが、v1はSSRFに対する脆弱性があるようなので無効化し、IMDSv2が使用されるように設定する。
- 下記を参考にセットアップ
Developers.IO | [待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセキュリティが強化されました! - AWSブログでは下記のような記載もあり、必要性を判断の上設定を行うのがよいか。新規ならV1は無効にしても不都合ないような気はするが。
https://aws.amazon.com/jp/blogs/news/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
既存のインスタンスメタデータサービス( IMDSv1 )は完全にセキュアであり、こちらも引き続きサポートします。
AWS Tools for PowerShellのセットアップ
- 使用するかどうかは別として標準ツールとして入れておくことにする
- 下記を参考にセットアップ
Developers.IO | AWS Tools for PowerShellのセットアップ手順 - EC2に設定するIAMロールを使用する前提のためCredentialは設定しない
#####(参考)PowerShell利用時のクレデンシャルの探索順序
- (非推奨)PowerShellコマンド実行時の引数に直接指定されているAccess Key IDとSecret Access Key
- 指定されたProfile Name、またはProfile Location
- -Credentialsパラメータで指定されたプロファイル
- セッションプロファイル
- defaultプロファイル
- IAM Roleが指定されているAmazon EC2インスタンスでコマンドを実行している場合、インスタンスプロファイルにあるEC2インスタンスクレデンシャル
Sysprep実行・AMI取得
そのままAMI取得してサーバーをコピー作成するとインスタンスセキュリティ識別子 (SID) 等の重複が発生してドメイン参加やWindows Server Update Services (WSUS)などで問題が発生する為、Sysprep を実行してインスタンスセキュリティ識別子 (SID)、コンピュータ名、およびドライバーを含む固有の情報を削除する。
- EC2環境の場合はEC2ConfigまたはEC2LaunchでSysprepを実行。
- Windows Server 2012 R2 まで: EC2Config
- Windows Server 2016 以降: EC2Launch
- Sysprepを実行すると最後にサーバがシャットダウンされるので、その状態のインスタンスのAMIを取得する。
- 参考手順
- Sysprepをしないとどういった動作になるかは以下のページに記載あり
参考:サーバ展開後に実施する作業
-
ドライブ追加
- Dドライブ以降を追加する場合は実施
https://dev.classmethod.jp/articles/attach_ebs_volume_to_windows-server/
- Dドライブ以降を追加する場合は実施
-
タイムゾーン設定
- テンプレート作成時に設定変更してもSysprepで設定がクリアされてしまう模様。
-
IPv6無効化
- EC2側でIPv6を有効にしていない場合は実施するのがベター
https://sanuki-tech.net/windows-server-2016/setup/network/
- EC2側でIPv6を有効にしていない場合は実施するのがベター
-
ネットワークの場所変更
- 必要に応じてネットワークの場所をパブリックまたはプライベートに設定
https://www.mosesu.xyz/wordpress/?p=213
- 必要に応じてネットワークの場所をパブリックまたはプライベートに設定
-
ファイウォールの無効化
- パブリックネットワークについてはテンプレートで無効化していてもSysprepで設定がクリアされ有効化されてしまう模様。パブリックネットワークに設定する場合は必要に応じて再度無効化。
-
ホスト名変更
-
Administratorユーザの無効化
- テンプレート作成時に設定変更してもSysprepで設定がクリアされてしまう模様。
- セキュリティ強化のためにAdministratorユーザの無効化を行う場合は実施。但しその場合は代わりにAdministrator権限を持つ別のユーザを作成しておくこと。
-
CloudWatch Agentインストール
- CloudWatch AgentはSystems Manager(SSM)から一括インストールが可能なので、後からインストールした方が設定修正なども発生しないだろうと考えてテンプレートにはいれなかった。
- 作業実施時は下記を参考に実施
Developers.IO | CloudWatch Agentを使ってWindows Serverのメトリクスを監視してみた
WindowsServerにCloudWatch エージェントを入れてリソース監視