巧妙化するサイバー攻撃などの外部脅威から企業の機密情報を守るために、特権IDの認証に多要素認証を組み込み、本人の識別を厳格にする対策は効果的です。

今回は特権アカウントに対する多要素認証対応の必要性や導入における課題について解説いたします。

多要素認証の必要性

昨今、企業の情報セキュリティにおいて取り上げられるゼロトラストにおいて多要素認証は必須であるとされています。なぜでしょうか。

ゼロトラストは、守るべきIT資産とセキュリティ上の脅威がともに、組織の内外に存在することを前提としてIT資産を守るための考え方です。ポイントはアクセスの都度、厳格に本人確認をし、そのアクセスの妥当性を検証すること。そのため、複数の認証の要素を組み合わせる多要素認証が必須となります。

IT資産であるシステムのアカウントは、一般アカウントと特権アカウントに区分できます。一般アカウントの管理でもゼロトラストの考え方は必要ですが、特権アカウントはシステムの最高権限を有する特別なアカウントであることから不正使用・誤用・濫用によるシステムへの影響が大きいため、より厳格な管理が必要であり、多要素認証を取り入れない理由はありません。

特権アカウントに多要素認証を適用する上での課題

しかしながら、特権アカウントに多要素認証を取り入れようとする際に、以下のような課題に直面し、容易に多要素認証を取り入れることが難しいのが現状です。

課題１：共有型アカウントに多要素認証が対応しない場合が多い

多要素認証の一般的な仕組みでは、各アカウントに所有者本人しか知り得ない、本人のみが提示可能な要素を紐づけるという考え方に基づいて動作します。例えば、佐藤さんのアカウントには、佐藤さんの指紋情報が紐づいて管理されており、認証時に指紋情報を要求し、紐づけられた情報と照合します。つまり、アカウントを利用するユーザーは常に固定されており、同一のアカウントを使いまわす想定にはなっていないのです。

しかし特権アカウントの管理においては、個人アカウントに特権を付与する方法ではかえって管理が煩雑になるため、共有アカウントを必要に応じて貸し出す運用が望ましいのです。

仮にこのような共有型アカウントに多要素認証を適用すると、貸し出すたびに、使用者が異なることが想定されるため、その都度、認証情報を付け替えるといった処理が必要になってきます。OTPを発行するトークンやICカードを貸し出すといった運用にも無理があります。

課題2：システムが利用することが想定される

サーバーの特権アカウントは、作業者が利用するだけではなく、バッチ処理などシステムが利用する場合があります。そのため特権アカウントに多要素認証を組み込んでしまうと、システムがアカウントを利用することが難しくなることがあります。

多要素認証システムの中には、特定のアカウントを除外し、多要素を必要としないよう設定することが可能なものも存在しますが、その場合は、従来のID・パスワードでの管理となり、不正使用のリスクレベルが従来のレベルのままになってしまいます。

課題3：多要素認証の管理・運用が煩雑になる

サーバーOS、ネットワーク機器、SaaS、IaaSの管理コンソールなどあらゆるシステムが特権アカウントを持っています。対応する多要素認証の仕組み、管理対象のシステム数によっては運用が煩雑になります。

例えば、ここに5つの異なるシステムがあるとします。すべてワンタイムパスワード（ソフトウェアトークンに対応）による多要素認証の仕組みであるとしても、Google Authenticatorなどのソフトウェアトークンに5つのシステムのアカウント情報を連携させ、管理する必要があります。管理対象のシステムをすべて同じ仕組みで運用できる場合は、それほど煩雑ではありませんが、例えば、Aというシステムのみソフトウェアトークンに対応していないため、ハードウェアトークンを使用する必要があるといったケースなどをイメージしていただくと、かなり煩雑になる可能性が潜んでいることが分かります。

パスワードの複雑性を強化する場合のジレンマ

一方、多要素認証を取り入れず、従来のID・パスワードを用いて認証を強化しようとすると、パスワードの最小文字数を長くしたり使用文字種を複雑にするなどの方法が考えられますが、パスワードは人による入力を前提としているため、極端に複雑で長いパスワードを設定することには限界があります。

文字数が多く入力に時間を要する他、誤入力によって何度も間違えてしまったり、アカウントがロックされてしまうなどのトラブルが発生しかねないからです。

多要素認証への対応ならエンカレッジ・テクノロジへご相談を

以上のように特権アカウントは、多要素認証に対応するにはいくつか問題がある一方、パスワードを複雑にするのも限界があり、認証強化を行うにはいろいろ制限が多いのが現状ですが、特権アカウント管理ツールを併用することで、運用上も無理をすることなく、認証強化を図ることが可能になります。

下図は、エンカレッジ・テクノロジの特権アカウント管理ツールESS AdminONEを使用した例です。

ESS AdminONEでは、ポリシーに基づいて、サーバーの特権アカウントとユーザーとの紐づけを行います。ユーザーがアクセスすると、シングルサインオンの仕組みを用いて、アクセスが許可されているサーバーへの認証をESS AdminONEが代行することで、特権アカウントのパスワードを通知せずにアクセス許可を行うことができる仕組みを提供します。このユーザーと特権アカウントとの紐づけはワークフローによる申請・承認で動的に設定することも可能です。

このような仕組みを用いることで、サーバーの特権アカウントは、人が入力することを想定しなくても良くなることから、非常に複雑なパスワードを設定し、かつ高頻度で変更することが可能となります。（ESS AdminONEは、パスワードの定期変更も自動処理します）

ESS AdminONEは、多要素認証は認証方式として、Google Authenticatorを使用するソフトウェアトークンとハードウェアトークンの両方に対応します。どちらの方式を利用するかは要件に合わせて選択し、ESS AdminONEを介して多様なシステムの特権アカウントを安全に使用することが可能です。