--- title: "管理者アカウントの守り方。多要素認証と緊急用のアカウント｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/protecting-admin-accounts/ description: "クラウドの管理者アカウントは、乗っ取られると環境のすべてを操作されるおそれがあります。ふだんは使わない運用、事業者が必須にしてきた多要素認証、緊急用のアカウントの作り方と保管、使われたことに気づく仕組みを、各社の公式の説明をもとに説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # 管理者アカウントの守り方。多要素認証と緊急用のアカウント クラウドの管理者アカウントは、乗っ取られると環境のすべてを操作されるおそれがあります。ふだんは使わない運用、事業者が必須にしてきた多要素認証、緊急用のアカウントの作り方と保管、使われたことに気づく仕組みを、各社の公式の説明をもとに説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - AWS のルートユーザー、Google Cloud の特権管理者のような強い権限のアカウントは、ふだんの作業に使わず、作業用の管理者アカウントと分けます。 - AWS・Microsoft Azure・Google Cloud は、管理者を含む人のアカウントに多要素認証を求める方向に進んでいます。フィッシングに強い方式を選びます。 - 緊急用のアカウントは、2つ以上用意し、安全な場所に保管し、使われたら知らせが届くようにし、定期的に使えるかを確かめます。 クラウドの管理者アカウントを守る基本は、強い権限のアカウントをふだんは使わないこと、多要素認証を、できるだけフィッシングに強い方式でかけること、そして通常のログインができなくなったときに備えた緊急用のアカウントを、使われたらすぐ気づける形で用意しておくことです。 ## 管理者アカウントは、なぜ別に守るのか 管理者アカウントは、乗っ取られると、データの持ち出し、資源の削除、ほかの利用者の締め出し、高額な資源の作成までできてしまうからです。クラウドの管理画面はインターネットのどこからでも開けるため、パスワードが漏れただけで入られるおそれがあります。 権限全体の絞り方は[クラウドの権限管理（IAM）の基本。最小の権限とは](https://www.ameliatechnology.co.jp/blog/cloud-iam-least-privilege/)で説明しています。この記事では、その中でも強い権限を持つアカウントの守り方を扱います。 ## 強い権限のアカウントは、ふだん使わない 各クラウドには、ほかのアカウントより強い権限を持つアカウントがあります。AWS のルートユーザー、Google Cloud・Google Workspace の特権管理者、Microsoft Entra ID の全体管理者などです。これらは、ふだんの作業には使わないのが基本です。 AWS は、ルートユーザーの資格情報が必要な作業以外ではルートユーザーを使わず、日々の作業には管理用の利用者を作ることを強く勧めています。ルートユーザーのアクセスキーは作らないこと、強く、ほかで使っていないパスワードを使うこと、ルートユーザーへのログインと利用を見張り、知らせる仕組みを持つことも挙げています。AWS Organizations を使う場合は、メンバーのアカウントからルートユーザーの資格情報を外し、ルートの操作を1か所にまとめる方法も示されています。 出典：[Root user best practices for your AWS account（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html) Google Cloud は、特権管理者には、ふだんのアカウントとは別に、別のログインが要る管理用のアカウントを渡すことを勧めています。日々の管理には特権管理者の役割は要らないため、組織の管理者を別に決めて任せるよう示しています。 出典：[Super administrator account best practices（Google Cloud）](https://docs.cloud.google.com/resource-manager/docs/super-admin-best-practices) ## 多要素認証は、事業者が求める方向に [多要素認証](https://www.ameliatechnology.co.jp/glossary/mfa/)は、管理者アカウントの守りの土台です。2026年11月時点で、3つのクラウドはいずれも、人のアカウントに多要素認証を求める仕組みを段階的に進めています。 | クラウド | 公式の説明の要点 | |---|---| | AWS | すべての種類のアカウントで、ルートユーザーに多要素認証の設定を求める。まだ設定していない場合は、最初のログインから14日以内に登録が必要。ルートユーザーには多要素認証の機器を最大8つまで登録でき、複数の登録が強く勧められている | | Microsoft Azure | 2024年10月から、Azure ポータルなどで作成・参照・更新・削除の操作をするアカウントに多要素認証を求めている（第1段階）。2025年10月1日から、Azure CLI・Azure PowerShell・IaC の道具などでの作成・更新・削除の操作にも段階的に求めている（第2段階） | | Google Cloud | 人が対話的に使うアカウントに、2段階認証プロセスを求める。開始の時期はアカウントの種類で異なり、たとえば SSO を使わない企業の Cloud Identity のアカウント（2026年8月3日より前に作られたもの）は、2026年10月20日以降 | 出典：[Root user best practices for your AWS account（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html)、[Plan for mandatory Microsoft Entra multifactor authentication (MFA)（Microsoft Learn）](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication)、[2-step verification requirement for Google Cloud（Google Cloud）](https://docs.cloud.google.com/docs/authentication/mfa-requirement) Microsoft の説明には、第2段階の開始の日付について画面の例と本文で表記の違いがあるため、自社のテナントに当てはまる日付は、管理画面の案内で確かめてください。方式は、AWS が勧めるパスキーやセキュリティキーのように、フィッシングに強いものを選びます。 出典：[Security best practices in IAM（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) ## 緊急用のアカウントを用意する 緊急用のアカウント（ブレークグラスのアカウント）とは、認証の仕組みの障害や設定の誤りで、通常の管理者がログインできなくなったときのために、別に用意しておくアカウントです。Microsoft は、Microsoft Entra ID の緊急用のアカウントについて、次のことを勧めています。 - 2つ以上用意する - 社内のディレクトリと同期・連携しない、クラウドだけのアカウントにする - パスキー（FIDO2）など、フィッシングに強い認証の方式を使い、ふだんの管理者アカウントとは違う方式にする - サインインを止めたり制限したりする条件付きアクセスの方針から外す - 使われるたびに知らせが届くようにし、サインインと操作の記録を見張る - 資格情報は、使ってよい人だけが知る形で、安全で離れた場所に保管する - 少なくとも90日ごとに、使えることを確かめる 出典：[Manage emergency access admin accounts（Microsoft Learn）](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) AWS のルートユーザーも、ふだん使わない強いアカウントとして、同じ考え方で扱えます。パスワードと多要素認証の機器の保管場所へのアクセスを記録して見張ること、そのパスワードでアクセスするアカウントの中のサービスに頼る道具には、パスワードを保管しないことが勧められています。 出典：[Root user best practices for your AWS account（AWS）](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html) ## 使われたことに気づく仕組み 強い権限のアカウントは、守るだけでなく、使われたときにすぐ気づける形にしておきます。ふだん使わないアカウントへのログインは、それ自体が知らせるべき出来事です。 - ルートユーザーや緊急用のアカウントのログインで、管理者の複数の人に知らせが届く - 知らせを受けたら、正当な利用かを誰が確かめるかを決めておく - 正当な利用でない場合は、[セキュリティ事故に備える、初動の手順書のつくり方](https://www.ameliatechnology.co.jp/blog/incident-response-plan/)で決めた初動の手順に移る 管理者の権限を持つ人の一覧と、最後に使われた日時を定期的に確かめることも大切です。棚卸しの進め方は[アクセス権の棚卸しと特権IDの管理の進め方](https://www.ameliatechnology.co.jp/blog/access-review-privileged-id/)で説明しています。 ## 当社のご支援 アメリア・テクノロジーの[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、管理者アカウントと緊急用のアカウントの設計、多要素認証の設定、ログインを知らせる仕組みづくりをご支援しています。管理者の権限を含めたクラウドの設定の点検は、[セキュリティ診断と対策](https://www.ameliatechnology.co.jp/service/security/)でもお受けしています。いまの状況は、無料の[クラウドの自己診断](https://www.ameliatechnology.co.jp/diagnosis/cloud/)でもおおまかに確かめられます。 - クラウド - 多要素認証 - 特権ID - セキュリティ ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [特権ID](https://www.ameliatechnology.co.jp/glossary/privileged-id/) - [多要素認証（MFA）](https://www.ameliatechnology.co.jp/glossary/mfa/) - [フィッシング](https://www.ameliatechnology.co.jp/glossary/phishing/) - [インターネット](https://www.ameliatechnology.co.jp/glossary/internet/) - [IAM（IDとアクセスの管理）](https://www.ameliatechnology.co.jp/glossary/iam/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「管理者アカウントの守り方。多要素認証と緊急用のアカウント｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/protecting-admin-accounts/