関連するソリューション
マネージドサービス（運用・保守）
先端技術部
エバンジェリスト 松岡 政之
こんにちは。先端技術部エバンジェリストの松岡です。
久しぶりのコラムですが先月部署異動し、先端技術部所属になりました。
しかし、私のミッションは大きく変わっておりませんので、引き続き
AWS
をいろいろいじっていきたいと思います。
私の趣味的な部分では、
AWD Ryzen
の新モデルが
11
月
6
日に発売されるのでとてもワクワクしています。前世代と同じく最大
16
コアですがシングルスレッドの性能が大きく伸び、
Intel
の
Core-i9 10900K
を上回るとも言われています。
その代わり価格は
16
コアで
10
万円を超える金額ですが、クリエイターなど
CPU
能力をたくさん必要とする層からすると素晴らしいコストパフォーマンスになると思われます。
前世代から性能が大きく伸びた理由の一つとして、
CPU
のコアとキャッシュをまとめた
CCX
が前世代では
4
コアだったのが
8
コアになり、コア間でデータを共有する際に
CCX
をまたぐやり取りが大きく削減され（
8
コア以下ではなくなり）レイテンシが大きく改善されたためといわれています。
私としては
Ryzen Threadripper
の
32
コア以上のモデルが出てから本番なので、来年値段とにらめっこしながら頭を悩ます未来がいまから見えます。
さて、今回の本題に入ります。
話題としては少し乗り遅れた感じはありますが、
AWS Single Sign-On (
以下、
AWS SSO)
が
9
月
3
日に東京リージョンでも利用できるようになりました。
※外部サイト：
AWS
の最新情報：
AWS Single Sign-On
がさらにアジアパシフィックの
3
つのリージョンで利用可能に
非常に有用なサービスなのですが東京リージョンで利用できなかったため、様々な理由で海外リージョンの利用が難しかった方々からすると待ちわびたアップデートではないでしょうか。
AWS SSO
がどういったサービスかは以下の公式ブログで簡単に説明されていますのでご確認ください。
※外部サイト：
AWS
ブログ：
AWS Single Sign-On
が東京リージョンで利用できるようになりました
それでは早速触ってみましょう。
まず、
SSO
のページに初めてアクセスすると以下のような画面になります。早速有効にしていきましょう。
AWS SSOの利用にはAWS Organizationsが必要になるため、まだ有効化していなければ組織の作成を促されますので組織の作成をしていきます。
AWS
組織の作成をクリックすると一度画面が切り替わり、しばらく待つとまた画面が切り替わります。
下記のような画面に切り替わると、問題がなければ
AWS SSO
が有効化されたことがわかります。
それではIDソースを選択から設定していきます。
ID
ソースは、「
AWS SSO
」、「
SAML 2.0
互換
ID
プロバイダー
(IdP)
」、「
Active Directory (AD)
」から選択できます。
「
AWS SSO
」を選択した場合は、
AWS SSO
ユーザポータルから認証する形になります。
「
SAML 2.0
互換
ID
プロバイダー
(IdP)
」は
SAML 2.0
に対応した外部
SSO
プロバイダーを利用して認証する形になります。
「
Active Directory (AD)
」を選択すると、同リージョンの
AWS Managed AD
や
AD Connector
を利用してオンプレミスの
AD
の認証情報を利用して認証する形となります。
AD
を利用した
SSO
は以前からありましたので今回は
AWS SSO
を選択してみます。
ユーザポータルについては、「カスタマイズ」をクリックすることで
1
度だけサブドメインを変更することができます。
画面に書いてある通り、あとから変更できないようなのでよーく考えて公開のない設定をしましょう。
続いて、多要素認証の設定をします。
設定ができるのは
MFA
が行われるタイミング、
MFA
未登録自の動作および管理できるユーザについてです。
続いて、左ペインの「ユーザー」から新規ユーザを作成していきます。
続いて、左ペインの「ユーザー」から新規ユーザを作成していきます。
グループについては今回はスキップしてユーザを作成します。
ユーザを作成すると、ユーザに設定した
E
メールアドレスに以下のようなメールが届きます。メールを受け取ったら
Accept invitation
からパスワードを設定します。
次に、管理画面に戻り左ペインのAWSアカウントからユーザの割り当てを行います。
先ほど作成したユーザを選択します。
アクセス権限セットの選択ではユーザに割り当てたい権限セットを選択します。
最初は権限セットがないので必要に応じて新しい権限セットを作成してください。
完了したら、ユーザポータルからログインします。
サインインすると先ほど割り当てを行ったため
AWS Accont
が選択できます。
クリックして開くと「
Management console
」と「
Command line or programmatic access
」を選択できます。
Management consoleを選択すると、以下のようにSSOから設定したユーザでマネジメントコンソールにアクセスできます。
Command line or programmatic accessを選ぶと、下記のようにAWSのアクセスキーが表示されます。
私個人的にはこのアクセスキーが個人ごとに利用できる仕組みが非常に大きいと思っています。
今回は
AWS SSO
を
ID
ソースとして利用しましたが、
AD
のユーザで認証したい場合を考えてみましょう。
AWS SSO
を利用しない場合、
Directory Service
からマネジメントコンソールのアクセス
URL
を作成することで
AD
アカウントでマネジメントコンソールにアクセスできるようになります。
しかし、この方法ではこのユーザに対してアクセスキーを払いだすことができません。
AD
アカウントを利用しているユーザがアクセスキーを必要とする場合は別途
IAM
ユーザを作成する必要があり、結局
AWS
上で追加のユーザアカウントを管理する必要が出てきてしまいます。
一方、
AWS SSO
を利用すれば上記の通り、簡単にアクセスキーを利用することができます。
今回は手元に
AD
がなかったこともあり
ID
ソースを
AWS SSO
にして検証しましたが、
Active Directory
を
ID
ソースとすることで
AD
ユーザに対して同様に設定が可能です。
また、今回紹介はしていませんが
Office365
や
GSuite
、
GitHub
などの
SAML2.0
対応の他サービスと連携することで、
AWS SSO
のポータル画面から直接他サービスにログインすることができるようになります。
ウィザード上から簡単に連携可能なサービスは
300
以上あり、個人的には
CloudEndure
や
Splunk
などが対応しているのが嬉しいです。
すでに
IAM
ユーザや
AD
アカウント用のアクセス
URL
を多くのユーザで利用している場合は、ログインの方法等が変わってしまうため展開し直すのはそれなりの労力がかかってしまうかもしれませんが、まだ他
ID
プロバイダーによる
SSO
サービスを利用していない場合は一考の価値のあるサービスだと思います。
特に、
AD
アカウント用のアクセス
URL
を利用している場合、
CLI
アクセス用の
IAM
ユーザとの二重管理となってしまっていると思いますので、重い腰を上げて切り替えてみると今後の運用がすっきりするかと思います。
AWS
は常に進化していますので、過去にできなかったことができるようになっていたり、目的のために一度使い始めたものよりより良い実現方法が登場していたりすることがあります。
しかし、新しい物を導入しようとすると今までの運用を大きく変更する必要がある場合もあります。そこは変更に伴う労力と変更後の付加価値や軽減される労力などを天秤にかけて決める必要がありますが、そこにめんどくさいという気持ちを天秤に乗せず、時には思い切って変えていく姿勢も必要でしょう！
それではよいクラウドライフを！
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
