業務委託先の不正アクセス–Oktaが直面した対応プロセスでの難しさ

今回は「業務委託先の不正アクセス–Oktaが直面した対応プロセスでの難しさ」についてご紹介します。

関連ワード （セキュリティ等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　ID・アクセス管理のクラウドサービスを手掛けるOktaは、2022年1月に取引先で発生した不正アクセスによるセキュリティインシデントへの対応に迫られた。事前に講じていた技術的対策によって同社と顧客への被害を防いだが、委託先とのやりとりでは困難な状況にも直面したという。事態に対処したAPJ担当リージョナルCSO シニアディレクターのBrett Winterford氏に、当時の詳しい経緯やこの対応で得た教訓などを話してもらった。

　今回のインシデントが発生したのは、Oktaがカスタマーサポートの対応業務を委託していたSitelになる。Sitelは約16万人の従業員を抱え、テクノロジーや金融、政府系を中心とした顧客のカスタマーサポート関連業務を受託して世界的にビジネスを展開している。

　Winterford氏によれば、SitelではOktaの顧客からの問い合わせに、Sitelの数人のカスタマーサポートエンジニアによるチームが対応していた。カスタマーサポートエンジニアが業務で利用するシステムはSitel内部に構築されており、ID管理の基盤にはActive Directory（AD）を利用していたという。

　顧客の情報はOkta側で管理されており、Sitelのカスタマーサポートエンジニアが顧客の情報を参照する時は、Okta側のシステムにアクセスする必要がある。その際には、まずSitel内部での認証を経てSitel内部にある仮想ワークステーションに接続する。そこからOkta側のシステムへのアクセスをOktaの認証情報で要求し、IDとパスワードに加えて別の認証方法を併用した多要素認証を行っていた。

　Oktaでは、Sitelなどの外部システムからOktaのシステムに対するアクセスを常時監視しているとのこと。インシデントは、2022年1月21日にOktaの監視でSitelからの通常のアクセスでは見られない不審な2つの動きを検知したことで発覚した。

　不審な動きの1つは、不自然なパスワードリセットの要求だったという。Winterford氏によると、パスワードリセットの要求は、Sitel内の仮想ワークステーションから行われる通常アクセスとは異なるネットワークからもたらされた。

　もう1つは、パスワードリセットの要求における正規ユーザーの反応だった。通常ではパスワードリセットの要求が発生すると、その要求が正しいものかをOktaが確認するために、正規ユーザーに多要素認証を要求しているという。この時は、パスワードリセットの要求したであろうはずのSitelのカスタマーサポートエンジニアが、リセットの実行に必要な多要素認証を拒否した。エンジニア本人がパスワードリセットの要求したのであれば、Oktaの多要素認証を実施しているはずである。

　また、パスワードリセットの要求に対するOktaの多要素認証は、ユーザーが指定しているメールアドレスに対して送信する仕組みだった。だがこの時は、正規のユーザーが指定しているメールアドレスではなく、Sitelの従業員が利用するMicrosoft 365サービスのメールアドレスに多要素認証の通知が行われた。この点にも不審さが認められたという。

　Winterford氏は、「これら複数の不審な兆候を検知したことにより、われわれはSitel側で不正アクセスのインシデントが発生している可能性を疑った。そこで、まず今回のOktaへのアクセス要求を拒否した上で、Sitelに対してインシデントの疑いを調査するよう求めた」と話す。