ID・アクセス管理のクラウドサービスを手掛けるOktaは、2022年1月に取引先で発生した不正アクセスによるセキュリティインシデントへの対応に迫られた。事前に講じていた技術的対策によって同社と顧客への被害を防いだが、委託先とのやりとりでは困難な状況にも直面したという。事態に対処したAPJ担当リージョナルCSO シニアディレクターのBrett Winterford氏に、当時の詳しい経緯やこの対応で得た教訓などを話してもらった。
Okta 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の多要素認証は、Oktaアカウントに設定されたセカンダリーのメールアドレスに対して送信された。このユーザーが指定しているセカンダリーメールアドレスは、Oktaが所有、管理、監視するアプリではないため停止を選択したという。
Winterford氏は、「これら複数の不審な兆候を検知したことにより、われわれはSitel側で不正アクセスのインシデントが発生している可能性を疑った。そこで、まずサポートエンジニアのOktaアカウントを停止した上で、Sitelに対してインシデントの疑いを調査するよう求めた」と話す。
