ここ2週間ほど、Alibaba Cloud のルートアカウント（Alibaba Cloud としての正式な呼称は Alibaba Cloud Accountですが）についてハードウェアのセキュリティキーによる U2F の設定を行うとかなり試行錯誤したのですが未だ成功しません(その話はこちら）。
やれることは大分やったのでいったんはU2F設定はあきらめようと考えています。 その代わりとしてハードウェアのセキュリティキー以外の方法でできる限りセキュリティリスク、具体的にはなりすましログインやトークンの窃取、を軽減する設定を実施する作業の記録です。
目次
セキュリティ強化の基本的な考え方
Alibaba Cloud ルートアカウントのセキュリティ強化の基本的な考え方を整理しました。
| 項目 | 私の環境での対応方針 |
|---|---|
| MFAの利用 | TOTPの利用 (本当はFIDOでハードウェアのセキュリティキーを使いたかったのですが） |
| IPアドレスの制限 | 実施しない。 自宅のISP割り当てのIPは変動可能性あるのと、別のクラウドに踏み台サーバを作るのはコスト面で非採用 |
| 強固なパスワード | 類推が難しい強固なパスワードに設定 |
| コンソールセッションの有効期限を最小 | 設定 |
| 操作保護（Operation Protection）の有効化 | Higher Strengthに設定 |
| 通知の有効化 | ログイン、セキュリティアラートを通知設定 |
| Access Key は作らない | ルートアカウントにAccess Key は存在しない状態 |
Alibaba Cloud 以外でも出来ることはあります。
- コンソール操作端末は固定化する（システム的にではなく、自らそうするという話）
- コンソール操作端末の強化としてEDR(Defender for Endpoint P2)を利用し、端末環境（Windows 11 ）のセキュリティを強化と監視
- 毎回、シークレットウィンドウ、プライベートブラウザでのコンソール接続
設定のポイント紹介
設定手順は省きますが、設定箇所やポイントを中心に紹介していきます。
ほとんどの設定は Account Center > Security Settings から行います。
アカウントのSecurity Settings の TOTPで設定します。
Mobile Phone は無効にします。 SIMスワップ攻撃やSMSインターセプト（電話番号ベースの乗っ取り）のリスクを減らします。
TOTP Authenticaton 1つのみとなりますが、Google Authenticator（や Microsoft Authenticator でも）で複数のデバイスで認証アプリを構成しておくことで片方のデバイスが故障、紛失しても認証は可能な状態を維持できます。
接続元IPアドレスで制限を行うことが可能ですです。 設定は Logon Mask から行うことが可能です。
私は設定していません。 理由としては個人利用のAlibaba Cloudとなり、自宅の光回線に割り当てられたパブリックIPアドレスで制限すると問題が起きえます。 固定IPではないためISP が払い出す IPが変わるとどこからもアクセス出来なくなります。
自宅のIP以外で例えばAzureやAWSに仮想マシン作ってそこでPublic IPを割り当てるという手段もなくはないですが、そこまでしたくはないという。 アイデアとしてパブリッククラウドで Public IPだけ購入しておくということも考えました。 本当に必要になったときに仮想マシンを作成するという考え方です。 でも今回はそこまではしません。 毎月数百円の出費もありますが、IPアドレスでの制限は多少の効果がある位にしか考えていないということもありました。
コンソールセッションの有効期限は Login Status から設定します。
最短の1時間に設定します。
Operation Protection から設定します。
“Higher Strength”にすることで、重要な操作（リソースの削除やパスワード変更など）が発生した際に、必ず2要素認証が必要になります。 トークンを窃取されたとしてもそのトークンでアクションを行おうとしたタイミングで2要素目が必要になるので不正行為の難易度を高めることができます。
通知の設定は大きく2つあります。 Security Center によるセキュリティリスク観点の通知と、Cloud Monitorを利用したログインや操作に関する通知です。
Security Keyによる通知は Message Center の Common Settings から”Accont Manage” で RecevingChannel を有効にします。
Alibaba Cloudでルートアカウントの操作（ログインやリソース変更など）を監視するには、ActionTrail（操作ログ記録） と CloudMonitor（システムイベント監視・アラート通知） を連携させる設定を行います。
まずは ActionTrail を有効化します。 普通は有効化していると思いますのでされていることの確認です。 されていないと Security Center から CSPM として警告されると思います。
ActionTrailの画面から Event Record にEventが記録されていればActionTrail は有効に機能しています。
あとは Trails の画面からも作成している Trail の一覧を確認可能です。
ActionTrailsで Alibaba Cloud 上の設定変更などのイベントは記録されていることが確認できたので次は監視や通知の設定となる Cloud Monitor の設定です。
Cloud Monitor の管理画面に移動し、左メニューの Event Center > Event Subscription から Subscription Policy を作成します。
Noise Redcution では “Directly triggered” を指定することで即時通知します。 not suppressed にすることで抑止も行いません。 場合によっては沢山の通知が発生するかもしれませんがここは情報を把握できないよりも把握できることを優先します。
通知方法も様々な方法が標準で準備されています ( 電話 / SMS / Mail / DingTalk / WeCom / SLACK)。 自分の環境に合わせて設定します。
最後のセクションの Push and Integration では Webhook や SLS (Alibaba Cloud Simple Log Service )などの外部連携を設定可能です。 必要に応じて設定します。
AccessKey の画面で ルートアカウント（Alibaba Cloud Account）にはAccess Keyは存在しないことを確認します。
まとめ
ほとんどの設定はすでに実施済でしたし、CSPMの観点で Security Cente がアラームを出してくれることもあり、特に対応が必要なものや設定変更を行うものはなかったのですが、定期的に自分の目で最新の情報をもとに1つ1つ確認していくことは有意義だとも思っています。 以前に設定していたらから大丈夫、Security Center からアラーム無いから大丈夫というのは全然大丈夫じゃないためです。 自分でもよくやるNG行動として、何かの作業のために危険な設定を一時的に行い（例えばいインターネットへのポートオープン）、そのうえでSecurit Centerの通知が煩わしいということで White List に入れる。 この解除を忘れてしまうとSecurit Centerからはアラームは飛ばないのにリスクは存在しうると。 なので定期的に自分の行動を疑って総点検することは大事だしセキュリティリスクの軽減としては効果的です。 ポジティブに他人は信用せず、自分も信用しない、ということです。
以上