TOP>コラム一覧>Amazon WorkSpaces始めます（その２）

Amazon WorkSpaces始めます（その２）

投稿日: 2020/12/18

こんにちは、園田です。
WorkSpacesの利用についての続きとなります。

Amazon WorkSpacesの設計（セキュリティ）

WorkSpacesはインターネット上にエンドポイントが存在することからDirectoryサービスを識別するRegistration codeとユーザID・パスワードが分かれば誰でもアクセス可能となります。
これではセキュリティ的に不安という方のために追加でセキュリティ強化の方式がいくつか用意されています。

Amazon WorkSpacesの設計（セキュリティ）

方式については以下の通り

  • 1. IP制限
    WorkSpacesのディレクトリサービスにて、「IP アクセスコントロールグループ」を作成し紐付けを行うことで許可されたIPのみWorkSpacesにアクセスさせることが可能

  • 2. 証明書
    OpenSSL等で発行したルート証明書をDirectoryサービスに導入。Directoryサービスにて証明書を有効にすることで、対応するクライアント証明書をインストールしたPCからのみアクセスを制限可能（ただし、Windows、MACのみ）

  • 3. 追加認証
    追加認証先として図で記載の通り、Free RadiusのIPアドレスを指定することで、追加認証を設定することが可能

なお、これらの方式を複数設定した場合、「＆条件」となります。どちらか１つのみという方式は取れませんのでご注意ください。
（部署によって方式を変更したいという場合、Directoryサービスを分けるなどの対応が必要です。詳細は「その１」を参照ください。）

それぞれの詳細を見ていきましょう。

1.IP制限

こちらの設定は「自宅から」ではなく、例えば「開発会社の方に自社内で開発をしてもらうため」など特定の会社からのアクセスのみ許可したいなどの場合に利用する機能になります。
IP制限を実施すると許可されたIP以外からアクセスした場合、「接続できません」の表示が実施され、ユーザID・パスワードの入力画面に遷移しません。

1つのディレクトリに対し、複数の「IP アクセスコントロールグループ」を設定可能となり、「IP アクセスコントロールグループ」１つにつき、25個までのIPを設定可能です。 開発会社が複数ある場合、会社ごとにIP アクセスコントロールグループを分けるなどの対応をすることで管理がし易くなります。

全てのDirectoryサービスにて利用でき、ユーザ側でのオペレーションも変更が無いメリットがありますが、特定の用途にしか利用できません。Simple ADと組み合わせにて利用が一般的かと思います。

2.証明書

OpenSSL等で証明書を発行し、Directoryサービス、およびクライアントPCへのインストールを行うことで、証明書をインストールした端末からのみの接続が可能となるものです。

この制御はWindowsとMACのみに有効になるため、他のOS（Web Access、iOS、Android、ChromeOS、ゼロクライアント、Linux）からはアクセスが不能となります。そのため、要件として、その他のプラットフォームからアクセスする必要がある場合は、この制御は利用できません。

2.証明書

証明書の期間ですが、設定にて任意に選択が可能です。
クライアントの証明書はデフォルトで1年になるため、1年ごとの更新にする。もしくはある程度の期間証明書更新をさせたくないため、10年での発行にするなどを設計する必要があります。多少技術的なことを載せたほうが良いかなということで、OpenSSLでの証明書発行手順を参考までに載せておきます。

なお、OSはAmazon Linuxの場合の手順となります。なお、Directoryサービスにはルート証明書を2つまで設定可能です。証明書を更新する際はルート証明書を追加することで簡単に更新可能です。

①OpenSSLをインストール

# sudo su ?
# yum update -y
OpenSSLがインストールされたことを確認
# rpm -qa | grep openssl
表示例：
openssl-devel-1.0.2k-8.107.amzn1.x86_64
openssl-1.0.2k-8.107.amzn1.x86_64

②証明局の作成

# mkdir -p /etc/pki/workspaces/newcerts
# cd /etc/pki/workspaces/
# echo "01" > serial
# touch index.txt
# cp /etc/pki/tls/openssl.cnf openssl_ca.cnf

コピーしたopenssl_ca.cnfを修正
# vi openssl_ca.cnf
--------------ここから----------------
[ CA_default ]の箇所を変更
dir = /etc/pki/CA 変更前
dir = /etc/pki/workspaces 変更後

[ v3_ca ]の箇所を変更
authorityKeyIdentifier=keyid:always,issuer 変更前
### authorityKeyIdentifier=keyid:always,issuer 変更後
keyUsage = digitalSignature,cRLSign,keyCertSign 変更後（追加）
--------------ここまで（設定変更を保存）----------------

root証明書を発行（10年の場合（必要に応じて日数を変更）
# openssl req -new -x509 -keyout cakey.pem -out cacert.pem -days 3650 -config openssl_ca.cnf

入力例
Enter PEM pass phrase:任意のパスワードを入力（ユーザ証明書のCSR作成で利用）
Verifying - Enter PEM pass phrase:任意のパスワードを入力（ ユーザ証明書のCSR作成で利用 ）
Country Name (2 letter code) [XX]: JP
State or Province Name (full name) []: Tokyo
Locality Name (eg, city) [Default City]: Shinagawa
Organization Name (eg, company) [Default Company Ltd]: sonoda.com
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:sonodaweb
Email Address []:

作成された「cacert.pem」をDirectoryサービスにインポートする。

③クライアント証明書用のCSRを作成

# cd /etc/pki/workspaces/
# mkdir Client
# cd Client
# openssl genrsa -out client.key 2048・・・・ ②
# openssl req -new -key client.key -out client.csr -sha256・・・・③
#cp /etc/pki/tls/openssl.cnf ./openssl_client.cnf
コピーしたopenssl_client.cnfを修正

--------------ここから----------------
# vi openssl_client.cnf
[ CA_default ]の変更
dir = /etc/pki/CA　変更前
dir = /etc/pki/workspaces　変更後
private_key = $dir/private/cakey.pem　変更前
private_key = $dir/cakey.pem　変更後
[ usr_cert ]の箇所
keyUsage = critical,nonRepudiation, digitalSignature, keyEncipherment,dataEncipherment　追加
nsComment = “OpenSSL Generated Certificate“　変更前
### nsComment = “OpenSSL Generated Certificate“　変更後
extendedKeyUsage = clientAuth　追加
--------------設定変更を保存----------------

④認証局に署名

クライアント10年証明書は以下のコマンドで発行
# openssl ca -config openssl_client.cnf -out client.crt -in client.csr -enddate 20310417235959Z
↑期限日をYYMMDDHHMMSSZに設定

※以下のエラーが出た場合は、 /etc/pki/workspaces/のindex.txtを削除しておくこと
failed to update databaseTXT_DB error number 2

※「The mandatory stateOrProvinceName field was missing」のエラーが出る場合は、
　エラーを無視する「 -policy policy_anything」を追加して再度コマンド実行を実施
# openssl ca -config openssl_client.cnf -out client.crt -in client.csr -policy policy_anything

⑤インストール用のクライアント証明書(p12形式)を作成

※必要に応じて各ユーザごとに発行していく
# openssl pkcs12 -export -in client.crt -inkey client.key -name 名前 -certfile ../cacert.pem -out ファイル名

例：
openssl pkcs12 -export -in client.crt -inkey client.key -name sonoda -certfile ../cacert.pem -out sonoda.p12
Enter Export Password: ※ユーザ毎の任意のPWを入力
Verifying - Enter Export Password: ※ユーザ毎の任意のPWを入力

作成された「sonoda.p12」をクライアントにインストール
補足：
「インストール用のクライアント証明書(p12形式)を作成」で作成したクライアント証明を
「共通で利用する」または、「ユーザ個別で作成する」ことが可能。
この場合、証明書を発行する際にパスワードを設定することが可能。
（「-name 任意の名前」で設定した名前がユーザから見える形になる。）

3.追加認証

Directoryサービスの「MFA認証」のタブにてサーバを設定することで、追加認証の設定が可能です。今回は無料で利用可能な FreeRadius + Google Authenticatorでの設定を例として記載します。

このFreeRadius + Google Authenticatorを利用した場合、利用者の登録について運用の手間がかかります。具体的には、「ユーザへQRコードの画像（もしくはURL）を送付し登録してもらう」などの必要があります。ユーザごとに登録するQRコードが異なるため手間がかかります。運用を行う場合はユーザ用の手順書を事前に配っておくなどの配慮が必要です。

また、このFreeRadius + Google AuthenticatorについてはAWSのサポート対象外（ベストエフォート対応）となるため、注意が必要です。きちんとしたサポートが必要といった場合は、サードベンダーのツールを使うことをお勧めします。（ただ、この構成で問題が発生したことは無いです。）

Amazon Linux利用時のFreeRadius + Google Authenticator 構築手順を以下に記載します。

①Free radiusを導入

# sudo su -
# yum -y update
# yum -y install freeradius freeradius-utils git gcc pam-devel qrencode qrencode-libs qrencode-devel

②RadiusサーバにGoogle Authenticatiorを導入

# yum -y install google-authenticator
インストール後、以下を確認
# ls -l /lib64/security/pam_google_authenticator.so

③OS & Radiusサーバの設定実施

# groupadd radius-enabled

# vi /etc/sysconfig/network
--------------
変更前 HOSTNAME=localhost.localdomain

変更後 HOSTNAME=hogehoge.example.com　←正しい名前を入力
NOZEROCONF=yes　←追加
NETWORKING_IPV6=no　←追加
IPV6INIT=no　←追加
--------------

# vi /etc/hosts
--------------
変更前 なし

変更後　XX.XX.XX.XX hogehoge.example.com　←　追加（正しいIPを追加）
--------------

# vi /etc/raddb/radiusd.conf
--------------
変更前
user = radiusd
group = radiusd

変更後
user = root　←　ユーザをrootに変更
group = root　←　グループをrootに変更
--------------

# vi /etc/raddb/users
--------------
変更前
#DEFAULT Group == "disabled", Auth-Type := Reject
#Reply-Message = "Your account has been disabled."

変更後
DEFAULT　Group != "radius-enabled", Auth-Type := Reject　←追加
Reply-Message = "Your account has been disabled."　←追加
DEFAULT Auth-Type := PAM　←追加
--------------

# vi /etc/raddb/sites-available/default
--------------
変更前　# pam
変更後　pam　←コメントアウトを外す
--------------

# vi /etc/pam.d/radiusd
--------------
変更前
auth　include　password-auth
account　required　pam_nologin.so
account　include　password-auth
password　include　password-auth
session　include　password-auth

変更後
# auth　include　password-auth　←　コメントアウト
# account　required　pam_nologin.so　←　コメントアウト
# account　include　password-auth　←　コメントアウト
# password　include　password-auth　←　コメントアウト
# session　include　password-auth　←　コメントアウト
auth requisite pam_google_authenticator.so　←　追加
account required pam_permit.so　←　追加
session required pam_permit.so　←　追加
--------------

# vi /etc/raddb/clients.conf
----------------------
変更前

変更後
client xx.xx.xx.xx/xx {　←　追加（※１）
secret = XXXXXXXX　←　追加（※２）
shortname = from-vpc　　←　追加
}　←　追加
----------------------
※１　xxにはVPCのアドレスを入力
※２　パスワードを入力（Directoryサービスの接続で利用）

# chkconfig --level 345 radiusd on
# reboot

④ユーザ登録（ユーザ作成時毎に実行）

# useradd -g radius-enabled xxxxx
# sudo -u xxxxxxx /usr/bin/google-authenticator
全て「y」を入力

⑤MFAデバイスを登録

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/xxxxx@xxxxxxxxxxxxxxx

というURLが表示されるので、URL画面に遷移しgoogle authenticatorで画像の読み込みを実施し登録

⑥疎通確認テスト

#radtest [ユーザID] [goole Authenticatorの数字] [radiusのIP:1812] 10 [上記で設定したパスワード]

例
radtest sonoda 123456 10.0.0.200:1812 10 sonoda123!

結果例
rad_recv: Access-Accept packet from host 10.0.0.209 port 1812, id=90, length=20

⑦Directoryサービスに設定

以下のような形で設定したFreeRadiusをDirectoryサービスに設定が可能です。
⑦Directoryサービスに設定

  • RADIUSサーバのIPアドレス : 作成したFreeRadiusのIPを指定ください

  • ポート : 1812を指定ください

  • 共有シークレットコード : 上記で設定したパスワードを指定ください

  • プロトコル : PAPを入力ください

  • サーバタイムアウト設定 : 任意の値を指定ください（10秒程度）

  • 最大試行回数 : 任意の値を指定ください（3回程度）

上記で「追加認証」となるFreeRadius + Google Authenticatorの設定は完了となります。

今回も長くなってしまったので、次回に続きます。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。

お問い合わせ

関連コラム

関連サービス

リモートワーク
リモートワーク
Amazon WorkSpaces
リモートワーク環境早期導入パッケージ
最短2週間でリモートワークを開始できるパッケージ Amazon WorkSpacesリモートワーク環境早期導入パッケージは、すぐにリモートワークを利用したいお客様向けに「短期間で利用開始」「手間がかからない」をコンセプトに、最短2週間でリモートワークを開始できるパッケージです。
詳細はこちら ＞

CTCが提供する
AWSソリューションパッケージ

クラウドエコシステム100 for AWS

ビジネス要求の高い機能を「すぐに使える」 ソリューションパッケージとしてご提供します！

  • 基幹システム移行

    基幹システム
    移行

  • 遠隔地バックアップ

    遠隔地
    バックアップ

  • 災害対策（DR）

    災害対策（DR）

  • セキュリティ

    セキュリティ

  • リモートワーク

    リモートワーク

  • デジタルマーケティング

    デジタル
    マーケティング

  • コンタクトセンター

    コンタクト
    センター

  • マルチCDN

    マルチCDN

  • コスト管理

    コスト管理

  • 統合システム運用管理

    統合システム
    運用管理

【著者プロフィール】

園田　一史（そのだ　かずし）

伊藤忠テクノソリューションズ株式会社　クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS（キュービック オン エーダブリューエス）」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年、2020年APN Ambassadorに選任。

園田　一史（そのだ　かずし）

TOP>コラム一覧>Amazon WorkSpaces始めます（その２）

pagetop