AWS ClientVPNの構成図 7パターン
AWSのClientVPNには認証方式が複数あります。
認証方式により、構成やUXが微妙に変わり、その質問をいただくことが多いため、
ユーザ視点でどんな感じになるのかを、7パターンで整理してみたいと思います。
これ以外にも構成パターンはあると思いますが、それらは応用編で、
もし機会があればブログ化してみたいと思います。
構成は、認証方式に依存する形となります。
紹介するパターンは下記です。
- ADオンプレで認証
- AD(AWS managed)で認証
- SAML(Okta)で認証
- ADオンプレ+証明書で認証
- AD(AWS managed)+証明書で認証
- SAML(Okta)+証明書で認証
- 証明書のみで認証
(1)ADオンプレで認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。 クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
ユーザ名、パスワードを入力します
認証に通ると接続されます。
運用考慮点
ADとclientVPNの接続許可設定を連動させることができます 。
（例：特定のOUの人が、xx.xx.xx.xx/xxへの疎通が可能）
その設定を変更する際は、ADとClientVPNの設定を変更する必要があります
(2)AD(AWS managed)で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)のパターンと同様です。
利用イメージ
(1)のパターンと同様です。
(3)SAML(Okta)で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい（ADと紐付け不要、ADの管理したくない場合）
- 認証はID管理サービスのログインでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス（Okta）のユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
Oktaでの認証を求められるためid/passでログインします。
Oktaの認証に通るとclientVPNに接続可能となります。
利用イメージ(ユーザ管理)
Oktaでのユーザ管理は下記イメージです。
私も初めてOktaを利用したのですが、特に迷うことなく直感的に操作できました。
ユーザ管理画面です。
ユーザ登録画面です。
(4)ADオンプレ+証明書で認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(5)AD(AWS managed)+証明書で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(6)SAML(Okta)+証明書で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい（ADと紐付け不要）
- 認証はID管理サービスのユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス（Okta）のユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(3)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(3)のパターンと同様です。
(7)証明書のみで認証
概要
こんな方向けです。
- 認証はクライアント証明書のみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
特にユーザ/パスワードを入力することなく接続が可能です
どのパターンが良いのか
まず最初に認証がユーザ/パスワードのみで良いかを考えると良いかと思います。
ユーザ/パスワードのみの認証で十分な場合には(1)(2)(3)が候補です。
(1)(2)(3)は既存でADを利用しているかどうかで決めると良いと思います。
Enterpriseでセキュリティが厳しい場合は、
ユーザ/パスワードと証明書による認証で(4)(5)(6)が候補です。
(4)(5)(6)は既存でADを利用しているかどうかで決めると良いと思います。
(7)は現実的に利用する方は少ないと思います。
上記をまとめるにあたり、初めてOktaを利用してみたのですが、
個人的にはOktaがかなり使いやすく、Oktaおすすめです。
小規模の会社で、試しにClientVPNを利用してみるぐらいでしたら
パターン(3)が良いのではと思います。
証明書は、セキュリティ強度は上がると思うのですが、
人件費等の作業コストがかかることを考えると
Oktaのようなサービス利用料の方が
トータルで安くなるのかと思います。
AWS SSOでGsuiteと連携した
会社でGsuiteを利用しており、AWSとSSO連携させてみました。
微妙にdocumentが分かりにくかったので、作業内容をブログ化してみました。
Gsuite側
まずは、Gsuite側の作業から入ります。
Gsuiteの管理者コンソールにログインする必要がありますので、
事前に管理者権限を割り当ててもらう必要があります。
ここでは、管理者コンソールにログインした前提で進めます。
IDPメタデータをダウンロードしておきます。
AWS側
今度は、AWS SSO側で作業します。
こちらで、先ほどGsuiteでダウンロードしたファイルをアップロードします。
ここで3つのURLを控えておきます。
Gsuite側
上記で控えたURL3つをGsuite側の設定に書き込みます。
AWS側
上記を終えたらまたAWS側に戻ります。
ここで、ユーザ名はgoogleのメールアドレスである必要があります。
（そうでないと後々エラーとなる。私はそれでハマりました）
ここで、SSOでログインした際に所有させたい権限を選択します。
良くあるものはawsが定義してくれており、
カスタマイズが必要な場合は自作もできます。
Gsuite側
最後にGsuite側で、ログイン可能とすべく、権限を特定ユーザor全員に開放します。
ログインイメージ
SSOのログイン画面にアクセスすると、下記のような画面が開きます
ここで、上記で設定した権限の一覧が出てくるので、ログインしたい権限で
Management consoleをクリックすると画面遷移できます。
また、クレデンシャルも払い出してくれます。
Tips
上記を試すまで下記が気になっていたので、試してみました。
Q：SSOでログイン後に、さらにスイッチロールは可能か？
A：可能でした
Q：Organization外のAWSアカウントにSSOから直接遷移することは可能か？
A：可能です。ただし受け側で下記作業が必要です。
static.global.sso.amazonaws.com
Q：cloudtrailにユーザ名はどのように残るのか
A：ユーザ名(メールアドレス)で残ります
オンプレからAWS RDSへの移行方法まとめ
オンプレからAWS(RDS)への移行方法をまとめてみました。
AWS Database Specialityの勉強をする過程で、
何かとまとめておくと、後々便利と思い自分のメモにしていたのですが、きれいにしたので公開してみます。
RDSの種類 * 移行方式の数があるのでかなりの量がありますね。
AWS AuroraのレプリカAutoscalingを時間指定で増減させる
Auroraのリードレプリカ数をAutoscalingできます。
時間指定でもできるのか試してみました。
結論を言うとできます。
AWS コンソールではCPU使用率、または接続数でスケールする設定しか
できないようなのですが、基本はなんでもできそうです。
autoscaling設定をした後に
CLIでcron形式で試してみたら普通にできました。
aws application-autoscaling put-scheduled-action \ --service-namespace rds \ --schedule "cron(50 * * * ? *)" \ --scheduled-action-name 'achaction' \ --resource-id 'cluster:test-xxxx-aurora-cluster' \ --scalable-dimension rds:cluster:ReadReplicaCount \ --scalable-target-action 'MinCapacity=1,MaxCapacity=1'
スケジュール削除もCLIで簡単にできます
aws application-autoscaling delete-scheduled-action \ --service-namespace rds \ --scheduled-action-name achaction \ --scalable-dimension rds:cluster:ReadReplicaCount \ --resource-id cluster:test-xxxx-aurora-cluster
AWS Appsync(GraphQL)の概要をRDB慣れした人向けに説明してみます
AWS Appsync(GraphQL)のDynamoDBチュートリアルを触ってみました。
チュートリアル : DynamoDB リゾルバー - AWS AppSyncdocs.aws.amazon.com
私はインフラよりの仕事が中心なので
多くのエンジニアと同じくRDBを触ったことがあるのですが、
GraphQLには馴染みがありませんでした。
と言うかGraphQL自体を初めて触りました。
そこで、同じ立場の人もいると思い、
RDBの感覚を含めてGraphQLの理解を書いてみたいと思います。
間違ってたらコメント頂けるとありがたいです。
GraphQLは何が良いのか
REST形式のAPIでは、一般的なアプリケーションで下記のようなことがありました。
* 欲しいレスポンスに応じてエンドポイントを複数用意する
* エンドポイント毎にリクエスト方式や、レスポンス内容等を理解する必要がある
* レスポンス内の一部の情報しか必要なくても決められた情報が全部返ってくる
GraphQLではこれらの点が改善されて使いやすくなっています。
* エンドポイントは1つのみ
* 欲しい情報のみをリクエストし取得できる
この違いを知ったときに、これってRDBに感覚近いのではと思いました。
上記以外にもまだまだメリットや変化点はあると思いますが、
詳しくはGraphQLのドキュメントを参照です。
簡単な例
こんな風にクエリを書いて
{
me {
name
}
}
こんなレスポンスをもらえると言う感じです。
{
"me": {
"name": "Luke Skywalker"
}
}
各用語の整理
GraphQLのマネージドサービスであるAppsyncの概要を整理してみます。
各用語の説明は下記です。
GraphQL スキーマ
GraphQLで受け入れ可能なスキーマを定義します。
RDBとかでいうところのテーブル定義に近いと思います。
SQLでも存在しないテーブルにSelectしようとしたり、
key項目なしでInsertしようとしたらエラーになるように、
GraphQLでの受入可能なクエリを定義します。
データソース
データソースは、GraphQL API で操作できる AWS アカウント内のリソースです。
AWS AppSync は、AWS Lambda、Amazon DynamoDB、
リレーショナルデータベース (Amazon Aurora Serverless)、
Amazon Elasticsearch Service、HTTP エンドポイントを
データソースとしてサポートしています
RDBで例えて言うと、各テーブルやviewでしょうか。
何の情報を、どのオブジェクトに持たせるのかを整理します。
リゾルバー
GraphQL スキーマとデータソースの関連づけを定義します。
どのリクエストを、どのデータソースと紐付けるかを設定します。
ここはRDBでうまく例えられませんでした。
新しい考え方として認識頂いた方が早いかもしれません。
多分リゾルバーが１番イメージの沸きにくいところなので、実際の設定画面をみてみます。
この画面左がスキーマです。右側にResolverとありますが、ここの「アタッチ」ボタンで
各スキーマとデータの紐付けを設定します。
この画面でデータソースを選択します。
リクエストマッピングテンプレートで、リクエストデータとスキーマをどのように紐付けるかを定義します。
レスポンスマッピングテンプレートでレスポンスデータとスキーマをどのように紐付けるかを定義します。
リクエスト実行の流れ
まだ分かりにくいと思いますのでリクエストを実行してみます。
Appsyncの画面からリクエストを実行可能なので流してみます。
ここではMutation(書き込みとそれに続く取得。RDBのinsert+selectに近い)を試してみます
リクエスト
mutation addPost {
addPost(
id: 123
author: "AUTHORNAME"
title: "Our first post!"
content: "This is our first post."
url: "https://aws.amazon.com/appsync/"
) {
id
author
title
content
url
ups
downs
version
}
}
クライアントが上記のaddPostと言うクエリを投げます。
type Mutation {
addPost(
id: ID!,
author: String!,
title: String!,
content: String!,
url: String!
): Post!
}
type Post {
id: ID!
author: String
title: String
content: String
url: String
ups: Int!
downs: Int!
version: Int!
}
type Query {
getPost(id: ID): Post
}
schema {
query: Query
mutation: Mutation
}
スキーマで、送られてきたMutationのaddPostが含まれているかを確認します。
上記では定義されているため、AppsyncはaddPostを受入可能です。
マッピングテンプレート
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($context.arguments.id)
},
"attributeValues" : {
"author" : $util.dynamodb.toDynamoDBJson($context.arguments.author),
"title" : $util.dynamodb.toDynamoDBJson($context.arguments.title),
"content" : $util.dynamodb.toDynamoDBJson($context.arguments.content),
"url" : $util.dynamodb.toDynamoDBJson($context.arguments.url),
"ups" : { "N" : 1 },
"downs" : { "N" : 0 },
"version" : { "N" : 1 }
}
}
まずは、Mutationを受け取り、リクエスト内容を読み替えます。
$util.dynamodb.toDynamoDBJson：
DynamoDB用のJSONにエンコードしてくれる便利な書き方
$context.arguments：
リクエスト内容を参照する、RDBで言うプレースホルダ的な書き方
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : { "S" : "123" }
},
"attributeValues" : {
"author": { "S" : "AUTHORNAME" },
"title": { "S" : "Our first post!" },
"content": { "S" : "This is our first post." },
"url": { "S" : "https://aws.amazon.com/appsync/" },
"ups" : { "N" : 1 },
"downs" : { "N" : 0 },
"version" : { "N" : 1 }
}
}
そして、Appsyncがリクエストマッピングテンプレートの定義に従い
GraphQLの形として下記に変換させます
上記では、operationがPutItemになっていますので
下記の内容がDynamoへのPutItemとして実行されます。
{
"id" : "123",
"author": "AUTHORNAME",
"title": "Our first post!",
"content": "This is our first post.",
"url": "https://aws.amazon.com/appsync/",
"ups" : 1,
"downs" : 0,
"version" : 1
}
そしてレスポンスマッピングテンプレートに
定義された項目がレスポンスとして返します。
下記は、そのまま返すの意味です。
$utils.toJson($context.result)
上記Mutationの流れにより、
DynamoへのPutItemが実行され、またその結果を得ることができます。
リクエスト側は、欲しい情報のみを記載するのと、
エンドポイントが複数にバラけないのが
フロントエンド側の実装としては嬉しいですね。
チュートリアルは、上記以外ににも、データをDeleteするパターンとかがあり 非常に分かりやすく纏まっていますので、ぜひ気になる方は試してみてください。
AWS Cloudwatch Synthetics GUIワークフロービルダーを使ってみる
AWS Cloudwatch Syntheticsで先日記事を書いてみたのですが、
「GUIワークフロービルダー」なる機能があったので使ってみました。
機能概要
サイトの動作確認等に利用が可能です。
サイト死活監視に加え、自動テストのようなイメージで
検索ボックスに「xxx」を入れて「検索」ボタンを押下して・・・・
といった感じで、サイトの監視＋動作確認を実施する機能です。
感覚としてはseleniumに近いです。
テストのシナリオ
今回は、下記シナリオで動作テストをしてみました。
- Amazonのサイト（https://www.amazon.co.jp/）を訪問
- 検索ボックスに「AWS」と入力する
- 検索ボタンを押下する
設定方法
Canaryを作成で、GUIワークフロービルダを選択します。
Amazonのwebサイトで、各要素のidを調べておきます。
各セレクタの項目が下記と分かります。
[id='twotabsearchtextbox']
[id='nav-search-submit-text']
こちらをCanaryの設定に入力します。
テキストを入力で「[id='twotabsearchtextbox']」とし、テキストを「aws」
クリックで「[id='nav-search-submit-text']」とします。
上記でCanaryを作成します。
結果確認
しばらくすると作成が成功します。
Cloudwatch Synthetics画面下部のスクリーンショットを確認します。
各画像を確認すると、きちんと設定した通りのスクリーンショットが作成されていました。
Amazonのサイト（https://www.amazon.co.jp/）を訪問
検索ボックスに「AWS」と入力する
検索ボタンを押下する
まとめ
AWS Cloudwatch Synthetics では、
上記のような複雑な動きの監視設定も可能になりました。
これらを1回だけ利用することもできるので、
単純に簡単なテストとしても利用可能かと思います。
使い方が広がりますね。
AWS Cloudwatch Syntheticsを試してみる（Route53との違い）
CloudwatchにSyntheticsの新機能が追加されたので使ってみました。
サイトの死活監視が可能なようで、
Route53のHealthCheckと少し被っているのかと思ったのですが、
Route53よりも、より詳細なリクエストを送ることが可能なようです。
まずはベーシックなハートビートのモニタリングを動かしてみました。
機能概要
ハートビートのモニタリングでは、
指定したURLへのリクエストが成功するかを検証します。
いわゆるサイトの死活監視です。
設定方法
対象のURLをAmazonのサイトにしてみます。
https://www.amazon.co.jp/
URLの欄を入力するとスクリプトに反映されるようです。
こちらで作成し、2~3分ほど待ちます。
作成されると裏側でS3やLambdaが自動生成されるようです。
多分裏ではcloudformation(SAM)が動いているっぽいですね。
実行後のイメージ
実行後に下記アウトプットが取得できました。
HARファイル
ログ
自動生成されたスクリプトが実行された際のログが出力されるようです。
S3へのエビデンス保存
さらに、上記がS3に保存されているため、過去に遡ってスクリーンショットを見ることができます。
aws s3 ls s3://cw-syn-results-xxxxxxx-ap-northeast-1/canary/www-amazon-co-jp-f81-bf25b112823a/successes/2020/05/03/14/05-37-778/ 2020-05-03 23:05:39 1265313 00-loaded-loaded.png 2020-05-03 23:05:39 105985 2020-05-03T14-05-19-265Z-log.txt 2020-05-03 23:05:39 678506 results.har.html
Route53との違い
Route53ヘルスチェックの死活監視との主な違いは下記かと思いました。
Route53のメリット
- 複数拠点から死活監視が可能
- 複数拠点からのリクエスト成功率を統計的に判断材料としている
Syntheticsのデメリット
Syntheticsは単一リージョンのLambdaからの死活監視なので、
例えば対象リージョンのLambdaに障害があった場合が心配です。
死活監視としては信頼性に弱みがあるかと思いました。
