組織がソーシャルメディアでのプレゼンスを管理するために、複数の担当者でアカウントを共有することはよくあります。しかし、ITチームやセキュリティチームにとっての課題は、こうしたアカウントの適切な使用をいかに徹底するかです。ソーシャルメディアアカウントの乗っ取りや認証情報の侵害は、ブランドのイメージや評判に深刻なダメージを与える可能性があります。
ソーシャルメディアチームとのみパスワードを共有し、決して変更しないというのは、効果的な戦略ではありません。チームによっては、パスワードマネージャーを使用してチーム内のメンバーが共有の認証情報にアクセスできるようにすることもあるでしょう。それで十分な場合もあります。
本記事では、Oktaを利用してソーシャルメディアサービスの共有アカウントへのアクセスを制御する方法について解説します。成熟度の低い順に次のようになります。
- Oktaで共有アカウントを持つSecure Web Authentication（SWA）アプリを使用する
- Okta Privileged Accessで手動によるSaaSサービスアカウントを使用する
- Okta Privileged Accessで自動化されたSaaSサービスアカウントを使用する
- Okta Privileged AccessでOkta共有アカウントをフェデレーション共有アカウントとして使用する
以下のセクションで詳しく説明します。
Oktaで共有アカウントを使用してSecure Web Authentication（SWA）アプリを利用する
Oktaは以前から、フェデレーションアカウントと非フェデレーションアカウントの両方を扱ってきました。フェデレーションアカウントは、Security Assertion Markup Language（SAML）やOpenID Connect（OIDC）などのフェデレーションシングルサインオン（SSO）プロトコルを活用し、パスワードを必要としません。非フェデレーションアカウントは、SaaSアプリのリポジトリに保存されているユーザーID/パスワードによるレガシーなアカウントであり、ログインプロンプトやHTTPヘッダー経由での認証情報の受け渡しによってアクセスされます。
プラットフォームの管理のために共有・使用されるアカウントについて言えば、通常は後者を指します。そこで、Secure Web Authenticationアプリの出番となります。SWAの仕組みによって、Oktaのアプリケーションに認証情報が関連付けられます。ユーザーがタイルを選択すると、ブラウザのプラグインで認証情報が挿入されます。
以下に、サインオン方法としてSWAを使用するようOktaで定義されたLinkedInアプリを示します。
認証情報のすべてのオプションの中で、この例では「ユーザーは管理者が設定した単一のユーザー名とパスワードを共有します」を使用しています。これらは、マーケティングチームがLinkedInにアクセスするために使用する共有の認証情報です。Oktaでアプリケーションを構成する際、管理者はそのアプリのユーザー名とパスワードを把握し、入力する必要があります。しかし、ユーザーにはその必要がありません。
割り当てられたユーザーのいずれかがダッシュボードでLinkedInのタイルをクリックすると、ブラウザプラグインが保存されているユーザー名とパスワードを取得し、アプリケーションのサインオン画面に挿入します。
Oktaの他のアプリケーションと同様に、割り当ては個人レベルまたはグループレベル、あるいはその両方で行うことができます。
理想的には、グループ経由で共有認証情報を使用してアプリへのアクセスを割り当てます。その後、グループのメンバーシップに関する制御を適用できます。グループルールを使用して、グループメンバーシップをユーザープロファイルの属性（例：Department = Marketing）に関連付けることができます。
Okta Identity Governanceの制御機能を使用してグループのメンバーシップを管理すれば、さらに効果的です。アクセスリクエスト機能を使用すると、承認フロー（マネージャーによる承認など）や時間制限（2時間のみアクセス権を付与するなど）を設けて、ユーザーにグループやアプリへのアクセスをリクエストさせることができます。アクセス認定機能を使用すると、アクセス権を持つユーザーが引き続きそのアクセス権を必要としているかを定期的に検証できます。
ソーシャルメディアアカウントのパスワードは自動的にローテーションされないことに注意してください。つまり、Oktaに保存されている値は、アプリ内の値と常に同期されている必要があります。アプリのパスワードが変更された場合は、Oktaに保存されているパスワードも一致するように更新しなければなりません。ただし、これを知る必要があるのは1人の管理者だけで、更新されたパスワードをチーム内で共有する必要はありません。これは完璧なソリューションではありませんが、チームメンバー間でパスワードをメールや紙で共有するよりも高いセキュリティを確保できます。
Okta Privileged Accessで手動によるSaaSサービスアカウントを使用する
Oktaは最近、Okta Privileged AccessでSaaSアプリケーションの共有アカウントを管理するための新機能を早期アクセスとしてリリースしました。これにより、ソーシャルメディアプラットフォームの管理に使用される共有アカウントなど、SaaSアプリの認証情報をOkta Privileged Accessのvaultに保存できるようになります。また、ポリシーを適用して、認証情報にアクセスできるユーザーや、認証情報を表示するために必要なプロセス（ジャストインタイムのアクセス承認、多要素認証の提供など）を制御できます。
この機能には2つのモードがあります。
- 1つ目は手動で、静的クレデンシャル（ユーザー名とパスワード）がvaultに保存されていて、アプリ内の認証情報が反映されます。アプリの認証情報が更新された場合は、それに合わせてvaultも更新する必要があります。
- 2つ目は自動で、アプリ向けのOkta Integration Network（OIN）インテグレーションがプロビジョニングに対応している場合です。これにより、Okta Privileged Accessが、そのソーシャルメディアアカウントのパスワードの管理元になることができます。
FacebookやLinkedInなどのソーシャルメディアプラットフォームは、手動のアプローチに依存しており、静的クレデンシャルを保存して、その表示方法を制御するためのポリシーを設定する必要があります。
Oktaは手動アプリのサインオンを実行しないため、このアプリはOktaではダミーアプリ（ブックマークアプリであり、ユーザーのダッシュボードには表示されない）として定義されます。それから、共有された認証情報がOktaにサービスアカウントとして保存されます。
Oktaに保存され、Okta Privileged Accessで割り当てられた共有アカウントを使用すると、ユーザーは（ポリシーに基づいて）ユーザー名とパスワードを表示できます。
Okta Privileged AccessのUIを使用してSaaSアプリを検索します。
次にアカウントを選択します。
アカウントには、ジャストインタイムのアクセス承認や多要素認証などの制御が関連付けられている場合があります。その後、認証情報を表示し、コピーしてソーシャルメディアアプリのログインフォームに貼り付けることができます。
以前のSWAアプローチと比較すると、このアプローチではエンドユーザーにパスワードが表示されます。また、パスワードが自動的にローテーションされないため、エンドユーザーがパスワードを書き留めて共有するリスクがあります。ソーシャルメディアプラットフォームのパスワードを定期的に変更し、vault内のコピーを更新するプロセスが必要になります。
このアプローチでは、認証情報へのアクセスをより厳密に制御することもできます。SWA方式はグループメンバーシップの制御に限定されていましたが、この方式ではMFAやアクセス承認などの追加の制御も適用できます。
このアプローチには、SWAアプローチにあるような認証情報を自動入力するためのブラウザプラグインがまだありません。
Okta Privileged Accessで自動化されたSaaSサービスアカウントを使用する
Okta Privileged AccessでSaaSサービスアカウントを使用するための2つ目のオプションは、アプリ向けのOkta Integration Networkインテグレーションを介して、Oktaからこれらのアカウントのパスワードを管理する方法です。これには以下が必要です。
- SCIMをサポートする統合があること
- その統合は、Okta Privileged Accessのパスワードローテーション機能をサポートすることがテストで確認されています。
このパスワードの自動管理をサポートするSaaSアプリの最新リストは、こちらでご確認いただけます。本ブログ執筆時点（2025年1月）では、このリストにあるソーシャルメディアアプリは、Workplace by Facebookのみです（ただし、Google Workspaceやその他のアプリもソーシャルメディアへのアクセスを管理するものと見なすことはできます）。
このメカニズムは上記と同じですが、共有アカウントのパスワードは、使用後および定期的にローテーション（Oktaで変更され、アプリにプロビジョニング）される点が異なります。こうすることで、パスワードはOkta Privileged Accessのみが把握することになります。ユーザーはパスワードを表示してアプリのログインプロンプトにコピー＆ペーストしますが、そのパスワードは一度使用されると置き換えられるため、書き留めて共有しても意味がありません。
Okta Privileged Accessはパスワードを管理し、使用後にローテーションするため、排他的なチェックアウトも実施でき、一度に1人のユーザーしかパスワードにアクセスできないようにします。共有アカウントへのアクセスを1人のユーザーに制限することに加えて、監査証跡によって個々のOktaユーザーと共有アカウントでのアクションを結び付けられるようになります。
このアプローチは、共有される可能性のある静的なパスワードが存在しないため、先の2つの方法よりも明らかに安全です。
フェデレーション共有アカウントに対するOkta Privileged AccessでのOkta共有アカウントの使用
最後に、ソーシャルメディアプラットフォームの管理に使用するアカウントを、共有のフェデレーションアカウント（パスワードなし、フェデレーションシングルサインオン（SSO）を使用してアカウントに安全に接続）にする方法があります。共有するパスワードは存在しません。アカウントにアクセスするには、Oktaのようなアイデンティティプロバイダーがシングルサインオン（SSO）を開始し、適切なトークンを渡す必要があります。では、Oktaでこれらのアカウントへのアクセスを管理するにはどうすればよいでしょうか？
Oktaにソーシャルメディアアプリにマッピングする専用のユーザーを作成し、そのユーザーをアプリにアクセスできる唯一のOktaユーザーにすることができます。ユーザーがソーシャルメディアアプリにアクセスするには、その特別なユーザーとしてOktaにログインし、タイルをクリックするしかありません。しかし、そうなると、特別なOktaユーザーアカウントにアクセスするための共有パスワードを持つという問題に逆戻りしてしまうのではないでしょうか？必ずしもそうとは限りません。
新しいSaaSサービスアカウント機能は、Oktaアカウントも対象としています。上記のようにOktaソーシャルメディアユーザーとOkta Privileged Accessを構成することで、そのソーシャルメディアユーザーとしてOktaにログインするための認証情報が、上記と同じ方法で表示されるように設定できます。ユーザーはOkta Privileged Accessにアクセスし、Oktaの特別なソーシャルメディア用ユーザーアカウントを表示して、その認証情報を使って当該ユーザーとしてOktaにログインします。その後、ソーシャルメディアのタイルをクリックすると、アプリにサインオンできます。完了すると、Oktaアカウントがチェックインされ、パスワードがローテーションされます。
理論的には、複数のフェデレーションソーシャルメディアアカウントを1つのOktaアカウントにまとめ、この方法でアクセスを管理できます。
この仕組みについて詳しくは、「Managing and Using Okta Shared Accounts with Okta Privileged Access」をご覧ください。
このアプローチでは、ソーシャルメディアアカウントのパスワードを管理するわけではありません（アカウントはフェデレーションされており、パスワードを持たないため）。管理するのは、そのフェデレーションされたソーシャルメディアアカウントへのSSOを可能にするOktaアカウントのパスワードです。
おわりに
Oktaで共有ソーシャルメディアアカウントを管理するには、さまざまなアプローチがあります。
一方には、既存のSecure Web Authentication（SWA）メカニズムがあります。これにより、管理者は共有のユーザー名とパスワードを保存でき、ブラウザプラグインを介してアプリのログインに挿入できます。これにはセキュリティ上の制限がいくつかあります。
次に、Okta Privileged Accessの新しいSaaSサービスアカウント機能を利用する方法もあります。この機能では、ソーシャルメディアの認証情報をvaultに保存し、アカウントの使用が必要になったときにマネージャーの承認を要求するなど、適切な制御で認可済みユーザーが認証情報を確認できるようになります。統合がパスワードローテーションに対応している場合、Okta Privileged Accessがこれらのアカウントのパスワードを管理します。
最後のアプローチとして、ソーシャルメディアプラットフォームがフェデレーションアカウントに対応しているものの、これらのアカウントを複数のユーザーで共有したい場合があります。このようなケースでは、これらのフェデレーションアカウント用に特別なOktaユーザーを作成し、Okta Privileged AccessのOktaサービスアカウント機能を使用して、必要に応じて適切な制御を行いながら、これらの特別なOktaユーザーにアクセス権を付与できます。
こうしたオプションは、さまざまなセキュリティ上の考慮事項を表しており、どの方法を選択するかは、ソーシャルメディアプラットフォーム、共有アカウントに対するそのプラットフォームのアプローチ、そして組織のリスク許容度によって決まります。パスワードマネージャーをご利用の場合でも、Okta Privileged Accessの新機能は、セキュリティの強化とリスクの低減に価値をもたらします。
