【ITニュース解説】おひとり様Organizations管理者もルートアクセス管理を有効にしよう！

AWSのようなクラウドサービスを扱うシステムエンジニアにとって、セキュリティ、特に「権限の管理」は非常に重要なテーマだ。今回は、AWSの強力なアカウント管理サービスであるOrganizationsと、その中に潜む「最強のアカウント」の危険性、そしてそれを管理するための特別な仕組みについて解説する。

まず、AWSアカウントについて理解を深めよう。AWSを利用する際、私たちはまず一つのAWSアカウントを作成する。このアカウントには「ルートアカウント」と呼ばれる特別なアカウントが自動的に生成される。これは、AWSアカウントを作成したメールアドレスとパスワードでログインする、そのアカウントの「究極の管理者」とも言える存在だ。ルートアカウントはAWS上のあらゆるサービス、リソースに対して無限の権限を持つ。想像できるだろうか、もしこのルートアカウントが不正アクセスを受けたり、誤った操作をしてしまったりしたら、その影響は計り知れない。そのため、AWSのベストプラクティスとして、ルートアカウントは日常的に利用せず、ごく限られた緊急時にのみ使うべきだとされている。普段の作業では、ルートアカウントでログインするのではなく、必要な権限だけを持つ「IAMユーザー」や「IAMロール」を作成し、それらを使って作業を進めるのが鉄則だ。

次に、AWS Organizationsについて説明する。システムが大規模になったり、複数のプロジェクトを並行して進めたりする場合、通常は複数のAWSアカウントを使い分けることが推奨される。例えば、開発環境用、本番環境用、セキュリティ監査用など、用途に応じてアカウントを分割することで、それぞれの環境を独立させ、セキュリティリスクを低減できる。この複数のAWSアカウントをまとめて管理するために提供されているのが、AWS Organizationsというサービスだ。Organizationsを使えば、複数のアカウントを一元的に請求管理したり、アカウントの作成や削除を組織全体で管理したりできる。さらに、Organizational Unit（OU）という単位でアカウントをグループ化し、そのOUやアカウントに対して「サービスコントロールポリシー（SCP）」という設定を適用できるようになる。

サービスコントロールポリシー（SCP）は、Organizationsの強力な機能の一つで、OUや個々のアカウントが実行できる操作を「ガードレール」のように制限する役割を持つ。例えば、「このOUに属するアカウントでは、EC2インスタンスの特定のタイプは作成できない」といったルールを設定できる。これにより、組織全体で一貫したセキュリティポリシーを適用し、誤った操作や意図しないリソース作成を防ぐことができるのだ。非常に便利なSCPだが、一つ大きな制限があった。それは、SCPは「ルートアカウント」には適用できない、という点だ。前述したように、ルートアカウントは究極の管理者であるため、SCPによる制限を受け付けなかった。

この「SCPがルートアカウントに適用できない」という点が、時に大きな問題を引き起こす可能性がある。今回のニュース記事の筆者は、S3バケットの設定で非常に危険な状況に直面した。S3バケットとは、AWS上でファイルを保存するためのストレージサービスだ。このS3バケットには「バケットポリシー」という、誰がどの操作をできるかを定義する設定がある。筆者はこのバケットポリシーの記述を誤ってしまい、なんと「バケットの所有者であっても、そのバケットを削除できない」という状態になりかけたのだ。通常、このような状況ではルートアカウントを使えば強制的に削除できると考えるかもしれない。しかし、もし「バケットの削除」自体をSCPで禁止していた場合、ルートアカウントにはSCPが適用されないため、この制限を迂回して削除できることになる。これは一見良いことのように思えるが、逆に言うと、たとえ組織全体で「重要なバケットは絶対に削除してはいけない」というSCPを設定していたとしても、ルートアカウントを使えばそのSCPを無視して削除できてしまうという危険性を意味する。

今回の問題の根幹は、たとえ組織全体にSCPで強力なガードレールを敷いていても、ルートアカウントだけは無制限に操作できてしまうという点にあった。そこで登場するのが、本記事の主題である「ルートアクセス管理（RMP: Root access Management Policy）」だ。これはOrganizationsの新しい機能で、SCPをルートアカウントに適用できるようになる、という画期的なものだ。RMPは、Organizationsの「ルートOU」という組織構造の最上位にSCPを設定することで実現する。通常、ルートOUにSCPを設定しても、その下のアカウントのルートアカウントには影響しなかったが、RMPを有効にすることで、その影響範囲をルートアカウントにまで広げることができるのだ。

具体的には、SCPの中で「aws:PrincipalArn」という条件キーを使って、「arn:aws:iam::*:root」という形式でルートアカウントであることを特定する。これにより、特定の操作をルートアカウントに対してのみ禁止するSCPを作成できる。例えば、ルートアカウントがS3バケットを削除する操作（s3:DeleteBucket）や、S3バケットポリシーを変更する操作（s3:PutBucketPolicy）を禁止するといった設定が可能になる。また、ルートアカウントのアクセスキーの更新（iam:UpdateAccessKey）を制限することも考えられる。これは、万が一ルートアカウントの認証情報が漏洩した際に、そのアクセスキーが悪用されるリスクを低減するためだ。筆者の経験のようにS3バケットのポリシーを誤って設定し、誰にも削除できなくなるような緊急事態に陥った場合でも、RMPによってルートアカウントの不適切な操作が制限されていれば、意図しない破壊を防ぎやすくなる。

RMPを導入することで、Organizations全体のセキュリティレベルは大幅に向上する。これまで野放しになりがちだったルートアカウントの権限を、組織のポリシーに沿って制御できるようになるからだ。これは、たとえ「おひとり様」でAWSを管理している場合であっても、非常に重要なセキュリティ対策となる。もし自分一人で複数のAWSアカウントを管理している場合でも、誤操作や不正アクセスによる被害を防ぐための「最後の砦」としてRMPは機能する。

ただし、RMPはあくまで「万が一の保険」であることを忘れてはならない。普段の運用では、IAMユーザーやIAMロールを使って、最小限の権限で作業を行うという基本的なセキュリティプラクティスを遵守することが最も重要だ。RMPによってルートアカウントに制限をかけることで、より安全な運用が可能になるが、そのSCPの内容を慎重に設計し、適用する前に十分なテストを行う必要もある。誤ったSCPを設定すれば、本当に必要な時にルートアカウントでの緊急対応ができなくなる可能性もあるからだ。

システムエンジニアを目指す皆さんにとって、クラウドサービスのセキュリティ管理は避けて通れないテーマだ。今回の話を通じて、AWSの「ルートアカウント」の持つ強大な権限とそれに伴うリスク、そしてOrganizationsやSCP、さらにはルートアクセス管理（RMP）といった仕組みを理解し、いかにしてそれらのリスクを最小限に抑えながら安全にシステムを運用していくか、その重要性を感じ取ってもらえれば幸いだ。常にセキュリティ意識を持ち、最新のベストプラクティスを学び続けることが、信頼性の高いシステムを構築するための第一歩となるだろう。