AWS における特権的アクセス権の管理を JIS Q 27002:2014 およびIAM ベストプラクティスに基づいて考える

AWS における特権的アクセス権の管理をJIS Q 27002:2014および、IAM ベストプラクティスに基づいて考えてみたいと思います。なお、この記事では、IAMに関する範囲で記載しています。EC2 OS レイヤーやアプリケーションレイヤーなどに関しては記載しておりません。

企業などの組織における情報セキュリティマネジメントシステム(Information Security Management System: ISMS) におけるベストプラクティスを定義した国際的な標準規格として、ISO/IEC 27000 シリーズがあります。

その中で、ISO/IEC 27002 はISMS 実践のための規範となります。より実践的にどのようにセキュリティに取り組むべきかが記載されています。

ここでは、ISO/IEC 27002 の日本版規格である JIS Q 27002 : 2014 「情報技術－セキュリティ技術－情報セキュリティ管理策の実践のための規範」(中身はISO/IEC 27002:2013) における「9.2.3 特権的アクセス権の管理」の定義と、AWS IAM ベストプラクティスに基づいてAWS における特権的アクセス権の管理を考えてみたいと思います。

※ 記載した内容が必ずしも皆様のビジネスにとって正しいということではありませんので、参考にしてもらいつつ、最適な方法を検討してください。

特権的アクセス権とは？
JIS Q 27002:2014 の参照方法
IAM ベストプラクティス
JIS Q 27002 「9.2.3 特権的アクセス権の管理」の内容
a)各々のシステム又はプロセス（例えば，オペレーティングシステム，データベース管理システム，各アプリケーション）に関連した特権的アクセス権，及び特権的アクセス権を割り当てる必要がある利用者を特定する
b) 特権的アクセス権を，アクセス制御方針（9.1.1 参照）に沿って，使用の必要性に応じて，かつ，事象に応じて，利用者に割り当てる。すなわち，利用者の職務上の役割のための最小限の要求事項に基づいて割り当てる
c) 割り当てた全ての特権の認可プロセス及び記録を維持する。特権的アクセス権は，認可プロセスが完了するまで許可しない
d) 特権的アクセス権の終了に関する要求事項を定める
e) 特権的アクセス権は，通常業務に用いている利用者 ID とは別の利用者 ID に割り当てる。特権を与えられた ID からは，通常業務を行わないほうがよい
f) 特権的アクセス権を与えられた利用者の力量がその職務に見合っていることを検証するために，その力量を定期的にレビューする
g) 汎用の実務管理者 ID の認可されていない使用を避けるため，システムの構成管理機能に応じて，具体的な手順を確立及び維持する
h) 汎用の実務管理者 ID に関しては，共有する場合に秘密認証情報の機密性を維持する（例えば，頻繁にパスワードを変更する，特権を与えられた利用者が離職する又は職務を変更する場合はできるだけ早くパスワードを変更する，特権を与えられた利用者の間で適切な方法でパスワードを伝達する）
まとめ

特権的アクセス権とは？

特権的アクセス権とは、よくroot 権限やAdmin 権限のように紹介されることがあります。
この定義で考えると、AWS においてはAWS アカウントのルートユーザに該当するかと思いますが、ここではもう少し広く捉えて、通常業務に必要な権限の範囲を超えて例外的に何らかの対応をしなければならず、より広い権限が必要となった場合のアクセス権の事を指すとします。

JIS Q 27002:2014 の参照方法

JIS Q 27002 はググると規格が公開された”もぐり”なページを参照できたりしますが、正式には、「日本産業標準調査会」の検索ページから参照してください。

日本産業標準調査会：データベース検索-JIS検索

上記URL で、”JISQ27002″ で検索すれば参照可能です。

IAM ベストプラクティス

以下のドキュメントを参照してください。

IAM のベストプラクティス – AWS Identity and Access Management

JIS Q 27002 「9.2.3 特権的アクセス権の管理」の内容

以下のような内容が列挙されています。

a) 各々のシステム又はプロセス（例えば，オペレーティングシステム，データベース管理システム，各アプリケーション）に関連した特権的アクセス権，及び特権的アクセス権を割り当てる必要がある利用者を特定する
b) 特権的アクセス権を，アクセス制御方針（9.1.1 参照）に沿って，使用の必要性に応じて，かつ，事象に応じて，利用者に割り当てる。すなわち，利用者の職務上の役割のための最小限の要求事項に基づいて割り当てる
c) 割り当てた全ての特権の認可プロセス及び記録を維持する。特権的アクセス権は，認可プロセスが完了するまで許可しない
d) 特権的アクセス権の終了に関する要求事項を定める
e) 特権的アクセス権は，通常業務に用いている利用者 ID とは別の利用者 ID に割り当てる。特権を与えられた ID からは，通常業務を行わないほうがよい
f) 特権的アクセス権を与えられた利用者の力量がその職務に見合っていることを検証するために，その力量を定期的にレビューする
g) 汎用の実務管理者 ID の認可されていない使用を避けるため，システムの構成管理機能に応じて，具体的な手順を確立及び維持する
h) 汎用の実務管理者 ID に関しては，共有する場合に秘密認証情報の機密性を維持する（例えば，頻繁にパスワードを変更する，特権を与えられた利用者が離職する又は職務を変更する場合はできるだけ早くパスワードを変更する，特権を与えられた利用者の間で適切な方法でパスワードを伝達する）

上記内容に対して、IAM ベストプラクティスと紐付けてAWS における特権的アクセス権の管理を考えていきたいと思います。

a)各々のシステム又はプロセス（例えば，オペレーティングシステム，データベース管理システム，各アプリケーション）に関連した特権的アクセス権，及び特権的アクセス権を割り当てる必要がある利用者を特定する

特権的アクセス権を利用できる運用者を特定しなさいということですね。

IAM ベストプラクティスには、「個々の IAM ユーザーの作成」という定義があります。

この考え方は、一つのIAM ユーザを複数の運用担当者で使いまわしてはいけませんということになります。使い回すということはすなわち、IAM 認証情報をみんなで共有するということです。このような運用をすると認証情報の流出に繋がりますので、運用者それぞれにIAM ユーザを割り当てることを推奨しています。

特権的なIAM ユーザをバイネームで運用担当者と紐付け、特定の運用担当者しか特権的アクセスができないようにしましょう。

IAM ユーザを複数作成して同じ権限を付与する場合は、「IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する」ようにしてください。

またこのときに同時に実施していただきたいのが「MFA の有効化」です。基本はすべてのIAM ユーザにおいてMFA は有効化してください。さらに特権的アクセスが可能なIAM ユーザに関しては、例えば、物理MFA デバイスにて設定しておき、普段はそのデバイスは鍵がかかる金庫や引き出しなどで管理し、その金庫もしくは引き出しの鍵の管理は別の人が行うなどの運用とすれば、特権的な操作ができる運用担当者がこっそりアクセスしてしまうといった自体を防ぐことが可能です。

MFA デバイスで利用できる種類は以下のAWS ページで確認できます。

IAM – Multi-factor Authentication

物理的なMFA デバイスは、USB に挿して利用する”U2F セキュリティキー(YubiKey)” もしくは、”ハードウェア MFA デバイス” で、単独の物理デバイスのボタンを押すとパスコードが表示されるもの2種類あります。それぞれの違いですが、U2F セキュリティキーは複数のエンティティ(ルートユーザやIAM ユーザ)で使い回すことができます。ハードウェアMFA デバイスは単一エンティティに紐づきますので使い回すことはできません。また、U2F セキュリティキーはマネジメントコンソールのMFA に利用できますが、CLIやAPI 呼び出しには利用できませんのでご注意ください。

b) 特権的アクセス権を，アクセス制御方針（9.1.1 参照）に沿って，使用の必要性に応じて，かつ，事象に応じて，利用者に割り当てる。すなわち，利用者の職務上の役割のための最小限の要求事項に基づいて割り当てる

これはすなわち最小権限の原則に従うということだと考えられます。特権的アクセスとはいえ、何でもできるような幅広い権限を与えてはいけません。

IAM ベストプラクティスでは「最小権限を付与する」にて定義されています。

特権ユーザとして実施すべき操作で最も考えられるのはIAM の変更作業だと思われます。通常運用に即したIAM 設定を、業務プロセスの変更やシステムの拡張などにより変更しなければならない場合が出てくると思います。このような場合のIAM の変更は特権的アクセスにて管理すべき内容だと言えます。（通常業務範囲でIAM の変更ができてしまうと、一般的な通常の運用者が自分自身の権限を変更できてしまうといったことが発生してしまいます。これは制限しないといけません。)

また、このベストプラクティス内にも記載していますが、最初から100 % 必要十分な権限を定義することは難しいと思います。なので、まずは最小の権限から運用を開始して、必要に応じて権限を増やしていくといった運用が良いかと思います。

この観点でさらに重要な点はセキュリティに関して、セキュリティの専門家が考えればよいというものではなく、チームメンバー全員がセキュリティに対して気を配るといった事が重要です。チームメンバー一人一人がセキュリティに関する高い意識を持ち改善し続けていくことが重要だと思います。

c) 割り当てた全ての特権の認可プロセス及び記録を維持する。特権的アクセス権は，認可プロセスが完了するまで許可しない

IAM の仕組みにより正しいアクセス管理を設定しておくということになるかと思います。

認可プロセスに関しては、例えばMFA デバイスは別の運用者が管理しておき、特権的アクセスが必要な操作を行うために、以下のような運用フローを実施するなどが考えられます。これは運用プロセスの話ですが、MFA の仕組みを上手く活用できます。

事前に作業内容を文書化してレビュー・承認するフローとする
その後、MFA デバイスの貸し出し申請などを行う
実際にIAM ユーザ認証情報とMFAデバイスにより作業を実施する

認可プロセスの記録という観点ではAWS CloudTrail を有効化しておけば特権的IAM ユーザによる認証・認可処理やその後の操作内容もすべて記録しておくことができます。ただし、この場合重要なのは、CloudTrail の設定を特権ユーザが無効化できてしまうと記録されなくなってしまいます。こうした意味で、特権ユーザでも操作できる範囲は限定しておくということが重要となります。
CloudTrail 以外のも記録やアクティビティの監視ができる機能があり、それらの機能を活用しましょう。この点に関しては、「AWS アカウントのアクティビティの監視」をご参照ください。

d) 特権的アクセス権の終了に関する要求事項を定める

これは運用フローにもよると思いますが、AWS 観点でいうと、作業が終わったら確実にログオフする運用とするなども考えらますが、特権的アクセスには有効期限を設け長時間特権的な権限でアクセスできないようにするということも考えられます。

これを実現するには、STS というサービスが利用できます。特権的アクセス権限を得るためにSTS のAssumeRole やGetSessionToken といった操作により一時的認証情報を得ることができます。この認証情報は一時的であるので有効期限が存在します。これを活用することにより特権的アクセス権が長時間有効な状態に居続けるということを避けることができます。

STS を利用した一時的認証情報に関しては、以下のドキュメントを参照してください。

一時的セキュリティ認証情報 – AWS Identity and Access Management

また、特権的な権限を持つIAM ユーザの認証情報は適切にローテーションするようにしてください。

認証情報を定期的にローテーションする

e) 特権的アクセス権は，通常業務に用いている利用者 ID とは別の利用者 ID に割り当てる。特権を与えられた ID からは，通常業務を行わないほうがよい

特権的アクセスは、例外的な対応が必要になった場合に行うようにしましょう。そのため通常業務で利用するIAM ユーザと特権的アクセスが可能なIAM ユーザは分けて定義するのが良いと思います。

この内容に関連して、IAM ベストプラクティスにおけるルートユーザを通常業務で使わないということも上げられます。この内容は「個々のIAM ユーザの使用」の中で言及されていますが、特権的アクセスでも同様です。ルートユーザは何でもできるスーパーユーザになってしまい権限を絞り込むことができません。

ただし、ルートユーザのみしかできないタスクも存在しますので、そういったタスクに関してはルートユーザを利用してください。ただしルートユーザのみが実施できるタスクは以下のドキュメントに明記されていますので、それ以外でルートユーザを利用する必要はありません。

AWS アカウントのルートユーザー認証情報が必要な AWS タスク – AWS 全般のリファレンス

f) 特権的アクセス権を与えられた利用者の力量がその職務に見合っていることを検証するために，その力量を定期的にレビューする

b) のところで述べた内容に相当します。最小権限の原則に従い必要な権限のみを付与してください。ただし、その権限が必要十分なのかは、定期的にレビューを行い確認するようにしてください、

アンチパターンとしては、ルートユーザを特権的アクセスに利用したり、特権的IAM ユーザにとりあえずAWS のすべての操作を許可するという運用は避けるようにしてください。

合わせて、IAM ベストプラクティス「アクセスレベルを使用して、IAM 権限を確認する」をご参照ください。

g) 汎用の実務管理者 ID の認可されていない使用を避けるため，システムの構成管理機能に応じて，具体的な手順を確立及び維持する

これはc) とe) に関連しますので、そちらを参照してください。

例えば、特権的なアクセスをする場合は、個人が知っている認証情報と別の人が管理しているMFA デバイスを同時に使用しないと、特権的なアクセスができなようにするといった運用が考えられます。

さらに、特権的アクセスにおいては、通常よりもより厳重に「追加セキュリティに対するポリシー条件を使用する」と良いです。

例えば、SourceIp を限定することで、特定の端末からしか特権的アクセスができないように制御することも可能です。

h) 汎用の実務管理者 ID に関しては，共有する場合に秘密認証情報の機密性を維持する（例えば，頻繁にパスワードを変更する，特権を与えられた利用者が離職する又は職務を変更する場合はできるだけ早くパスワードを変更する，特権を与えられた利用者の間で適切な方法でパスワードを伝達する）

これは、a) にて述べたように、基本は個人ごとにIAM ユーザを作成して個人で認証情報(パスワード)を管理するようにしてください。ただし、運用上、特権的操作ができる運用者を個別にバイネームで指定できない場合は、特権的アクセスが可能なIAM ユーザの認証情報(パスワード)を共有するといった運用が必要となる場合もあります。

その場合は、認証情報の共有は非常に気をつけて行ってください。MFA デバイスは別に管理するというのも有効です。さらに頻繁に認証情報を変更するようにしてください。離職者が出た場合は必ずその都度認証情報を変更する必要があります。

ただ、認証情報を共有するような運用はやはりおすすめはできませんので、できればIAM ユーザを個別に払い出してパスワードは共有しない運用が安全だと思います。

そもそもパスワードは「ユーザーの強力なパスワードポリシーを設定」するようにしてください。

まとめ

特権的アクセスを管理する場合、IAM ベストプラクティスに則り適切な管理をするようにしましょう！

以上です。