AWSのIAM、Cloudtrailの概略、IAMとIT内部統制との関連について

最終更新日：2026年8月10日

はじめに

項目	AWS	Microsoft Azure	Google Cloud
世界シェア	約33%（首位）	約22%	約11%
強み	サービス数・実績	Microsoft製品連携	データ分析・AI
無料枠	12ヶ月+常時無料	12ヶ月無料	常時無料枠あり
主な資格	CLF / SAA / SAP	AZ-900 / AZ-104	ACE / PCA

ITによる内部統制を整備すべく様々な取り組みが行われている中で、考慮すべきなのがIAM（Identity and Access Management）といえます。IAMの基本体系を理解することが、今、自社に必要な対策とは何かを認識する際の一助になることは間違いありません。そこでIAMについて概略を確認することにします。

AWSにおけるID/アカウント情報

AWSリソースにアクセスするID/アカウント情報には、AWSアカウント作成時のIDであるルートユーザーと、IAMサービス上で作成するIAMユーザーの2種類があります。ルートユーザーは、AWSアカウント作成時のEメールアドレスがログインIDとなり、すべてのAWSサービスとリソースに完全なアクセス権を持ちます。ルートユーザーは日常的には使用しないことが推奨されています。IAMユーザは、付与された権限の範囲でAWSリソースへのアクセスが可能となるユーザです。通常運用時には、IAMユーザーを作成し使用することが推奨されています。

IAMとは

IAMとはIdentity and Access Managementの略であり、アイデンティティ管理とアクセス管理を指します。アイデンティティをユーザーIDと考えると、IT環境にアクセスする際は必ずユーザIDを使用してリソースにアクセスするため、この管理は重要です。また、アクセス制御、すなわちアクセスの許可/拒否はIT環境の統制をとるために必須の機能であるため、アクセス管理も同じく重要となります。

IAMの構成要素

IAMユーザーとIAMグループ

IAMユーザーは、１つのAWSアカウント当たり5000ユーザーまで作成可能で、ユーザーごとにユーザー名/パス/所属グループ/パーミッション（権限）を設定できます。IAMグループはIAMユーザーを取りまとめる役目とアクセス権限を与える役目があります。1つのAWSアカウント当たり300グループまで作成できます。グループ名/パス/パーミッションを設定できます。IAMユーザーの認証情報には、AWSマネジメントコンソールにログインするときのユーザー名/パスワード、AWSサービスへのAPI操作が可能なアクセスキーID/シークレットアクセスキー、SOAP形式のAPIリクエスト用のX.509証明書があります。認証メソッド（認証方法）には、パスワードとMFA（多要素認証）を利用できます。パスワードは、パスワードポリシーによって強固に管理できます。MFAは、ハードウェアMFAおよび仮想MFA/セキュリティキー（U2F/FIDO2対応のパスキーを含む）を使用できます。

IAMポリシーとIAMロール

IAMポリシーはできること/できないこと を定義し、IAMユーザーやIAMロールに紐づけて使用します。IAMポリシーには複数のユーザー/グループ/ロールにアタッチできる管理ポリシーと、個々のユーザー/グループ/ロールにしかアタッチできないインラインポリシーがあります。AWSサービスに対してよく利用される権限がまとめられており（例：AmazonDynamoDBFullAccessなど）、これを使用することにより簡単に権限を指定することができます。また自分で権限を作成することもできます。IAMロールは、AWSサービスやアプリケーションなどのエンティティに対してAWS操作権限（IAMポリシー）を付与するための仕組みです。IAMロールはSTS（一時的セキュリティ認証情報）の仕組みを用い、アプリケーションから認証情報が漏洩することを防ぎます。

AWS CloudTrailによるIAMおよびAWS STSのAPIコールのログ記録

CloudTrailは、AWS APIの全ての呼び出しについて、それを行ったユーザやIPアドレス、リクエストやレスポンスの詳細を記録し、そのログをS3に出力してくれるサービスです。このサービスがあることにより、不正アクセスがあった場合の追跡が可能になります。また「記録されているから」という心理的な抑止効果も期待できます。また、CloudTrailが無効にされた場合は、AWSの通知サービスであるSNS(Simple Notification Service）を利用することで通知を行うことが可能です。より体系的に運用したい場合は、AWS ConfigのマネージドルールやAmazon EventBridgeと組み合わせて、CloudTrailの停止や設定変更を自動検知する構成も広く採用されています。

IAMをつかったIT内部統制とは

IT環境にアクセスする際にはユーザIDを使用します。誰がどのような役割を持ち、役割を遂行するため何にアクセスできるようにするか（あるいは、できないようにするか）、そして実際に何にアクセスしたのか──このような内容はすべて「ユーザID」をベースに制御・管理が行われます。ユーザIDが実際の人物とマッチしている必要がある訳で、実在しない人物のIDが存在し、それが使用されている、あるいは実際の職種では扱う必要のない他部門のデータにアクセスできるといった状況では、IT統制が取れた環境であるとはいえません。この管理をきちんと行うため、インフラ・基盤としてまずIAMを整備すると、IT統制に効果が発揮されます。

押さえておきたいポイント

• ルートユーザーは初期設定やごく一部の管理操作のみに使用し、日常運用ではIAMユーザー（または後述のIAMロール）を使うのが原則。
• IAMグループでユーザーをまとめて権限管理することで、個別付与によるミスや権限の肥大化を防ぎやすくなる。
• CloudTrailによる操作ログの記録は、内部統制上の証跡確保だけでなく、不正アクセスの早期発見・追跡にも直結する。

よくある質問

IAMユーザーとIAMロールはどう使い分ければよいですか？

特定の人が長期的に使うアカウントにはIAMユーザーを、EC2やLambdaなどのAWSサービスやアプリケーションが一時的に権限を借りる場合にはIAMロールを使うのが基本です。IAMロールはSTSの一時的な認証情報を利用するため、アクセスキーを埋め込む必要がなく、認証情報の漏洩リスクを抑えられます。

IAMのベストプラクティスとしてまず何をすべきですか？

ルートユーザーへのMFA設定、ルートユーザーの日常利用停止、IAMユーザーごとの最小権限の付与、パスワードポリシーの適用が基本の第一歩です。あわせてCloudTrailを有効化し、操作ログをS3等に保全しておくことも推奨されます。

CloudTrailのログはどのくらいの期間保存すればよいですか？

内部統制やセキュリティ監査の要件によって必要な保存期間は異なります。CloudTrail自体のイベント履歴機能は直近90日分を無料で参照できますが、それ以上の長期保存が必要な場合はS3バケットへの出力とライフサイクル設定、必要に応じてAWS CloudTrail Lakeの利用も検討してください。

おわりに

今回はAWSのIAMの概略と、IAMとIT内部統制の関係を簡単に説明しました。IAMはAWS リソースへのアクセスを安全に管理するためのウェブサービスであるにとどまらず、IT内部統制に役立つサービスであることを記述しました。ぜひこの機会に導入を検討してみてはいかがでしょうか？

参考文献:
https://www.wafcharm.com/blog/aws-iam-for-beginners/
https://japan.zdnet.com/article/20368582/2/