クラウドセキュリテイを考える上で重要な要素に「設定ミス」があります。これまでもAWS S3やセールスフォースのユーザ権限等の設定ミスによって「意図せぬ情報漏えい」を起こしてしまった企業は少なくありません。

　こういった「設定ミス」に今後はユーザ認証を司る「IDaaS」が加わるかもしれません。

　セキュリティ企業のauthomizeはIDaaSのリーディングカンパニーであるOKTAのデフォルトの設定が原因で起こり得るセキュリティリスクを発表しました。

■Oktaの設定ミスによって発生する4つのリスク

　authomizeは、OKTAには4つのリスクが存在していると主張しています。

　1.SCIMを介したパスワードの平文抽出

　Oktaで"App Admin"の権限を与えられたユーザアカウントを利用して、特定のアプリに割り当てられたIDやパスワードを抽出する攻撃が可能です。"App Admin"がSCIMプロビジョニングサーバを指定する際に、サイバー攻撃者が実行しているSCIMプロビジョニング用のサーバを指定すると、そのアプリに割り当てられた全アプリユーザの全Oktaパスワードを抽出することが可能になります。

　2.暗号化されていないチャンネル（HTTP）上でのパスワードや機密データの共有

　SCIM over HTTPを利用してOKTAとSCIMプロビジョニングサーバー間をHTTPSではなく、HTTPで構成している場合にはサイバー攻撃者が盗聴可能である場合に両システムの間で交換されるクリアパスワードを盗聴可能になります。

　3.ハブ＆スポーク構成により、サブ組織の管理者がハブや下流の他のスポークのアカウントを侵害することができる。

　Oktaには大規模なグループ企業を統括するためにハブ&スポークと呼ばれる構成をとることが可能です。ハブ&スポーク機能を使うと組織は複数のOktaテナント（Okta Orgsとも呼ばれます）を統合しシングルサインオン（SSO）やプロビジョニングを行うことが出来るようになります。

　便利な機能ですが、ハブの管理者権限を持つアカウントと同一の識別子を持つユーザアカウントがスポーク側に存在し、それにスポーク環境での管理者権限が割り当てられていた場合には、ハブ側の管理者になりすますことが可能になります。

　4.可変IDログのなりすまし

　Oktaユーザはデフォルトで自身の姓名を編集可能です。これによりアクセスログ等に表示される「ユーザの表示名(DisplayName)」が変更されます。

　もし、サイバー攻撃者がこれを悪用した場合には一時的に「犯人にしたい」ユーザ名に変更し不正な動作を実行し、アクセスログ上に「異なるユーザ名」を記録されることが可能になります。実際にはDisplayNameの他に「AlternateID」も記録されているのでそちらを確認することで、本当のユーザIDが誰なのかがわかりますが、そういった知識がないSoC担当者の目を欺くことが可能になります。　

■Oktaの見解は脆弱性ではなく、仕様

　authomizeは上記の4つのリスクについてOktaに見解を求めたところ、Oktaの脆弱性ではなく仕様であるとの回答だったとしています。

　確かにSCIMの動作等はOktaに限った話ではなくSCIMを利用するその他のIDaaSにも言えることでしょう。しかし、ハブ&スポークの同一ユーザ名に起因するものや、可変IDログの問題は「便利な機能」ではあるもののそれを利用する上での懸念点は補足する必要があるのではないかと感じます。

　Oktaは良いIDaaSソリューションです。しかし、IDの管理に係わる重要なソリューションであるため、S3の設定ミスやセールスフォースの設定ミス等と比べても、サイバー攻撃者に悪用された時の被害は甚大になる恐れがあります。

　IDaaS製品を導入する場合には、リスクとなりえる設定となっていないか十分に評価することを推奨します。