楽天グループ3社のクラウド型営業管理システムが第三者の海外からのアクセスがあり、最大148.6万件の情報が流出した可能性があると発表しました。
xtech.nikkei.com
楽天は2020年12月25日、クラウド型営業管理システムに保管していた情報の一部が社外の第三者から不正アクセスを受けていたと発表した。楽天のほか、楽天カードや楽天Edyも被害に遭い、最大で延べ148万件超の顧客情報が不正にアクセスできる状態だった。日経クロステックの取材で、このクラウド型営業管理システムが米salesforce.com（セールスフォース・ドットコム）のシステムだったことが分かった。
不正アクセスの原因は、楽天がクラウド型営業管理システムのセキュリティー設定を誤ったことにある。2016年に同システムのアップデートがあった際、セキュリティー設定のデフォルト値が変わったという。再設定が必要だったが、できていなかった。2020年11月24日の社外のセキュリティー専門家からの指摘をきっかけに、設定の誤りが判明。社内のセキュリティー専門部署を中心に対応し、2020年11月26日までに正しい設定に直した。
（日経XTECH記事より引用）
公式発表
・クラウド型営業管理システムへの社外の第三者によるアクセスについて（楽天）12/25
・【お知らせ】当社一部製品をご利用のお客様におけるゲストユーザに対する共有に関する設定について（セールスフォース）12/25 ※関連情報
キタきつねの所感
昨日夕方にこのニュースを聞いたのですが、時間があまり取れずに公式発表を見れていませんでしたが、流石日経XTECHさんと言うべきか、既に原因部分まで取材されていて、Salesforceの設定ミスであったと断定しています。
（以下、不要な調査かとは思いますが、SalesForce設定ミスだったのか自分なりに調べてみると・・・）
改めてその視点で見てみると、楽天が発表した同日にSalesforceがリリースを出していますし、元々の楽天の発表がSFAとしてSalesforceが全世界シェアNo1である「クラウド型営業管理システム」と書いています。
また、Salesforceの「事例紹介」の中には、今回被害を受けた楽天Edyが出ていましたので、今回影響を受けた楽天グループ3社（楽天、楽天カード、楽天Edy）がSalesforceを利用していた可能性は非常に高いと言えます。
www.salesforce.com
インシデントの影響範囲について、3社合計で、現時点で海外からの不正アクセスが既に確認されており、3社合計で1,486,291件の企業や個人情報が流出した可能性があると発表されていますが、現時点で614件（楽天208件＋楽天カード304件＋楽天Edy102件）の情報が既に漏えいしたと見られており、不正アクセスが実際に確認された件数から考えると”ハッカーの様子見”な攻撃だった気がしますが、今後の詳細調査により、更に深刻な影響だったと発表される可能性があるかも知れません。
2．社外の第三者からのアクセスの可能性があった情報
楽天株式会社：
「楽天市場」への法人向け資料請求者および店舗情報
項目： 一部の出店見込/契約済事業者の企業名、店舗名、住所、代表者名、担当者名、電話番号、Fax番号、メールアドレス、営業対応情報等
可能性があった期間： 2016年1月15日（金）-2020年11月24日（火）
可能性があった最大件数： 1,381,735件（うち、現時点でアクセスが確認された件数： 208件）
※詳細については以下のリンク先もご参照ください。
https://event.rakuten.co.jp/top/announce/20201225/
楽天カード株式会社： 事業者向けビジネスローン申込者情報
※楽天カード（楽天ビジネスカード含む）会員様の情報は、別のシステムにて管理しているため、本事象による影響はございません。
・対象となるお客様： 2013年4月1日（月）-2020年7月18日（土）に、ホームページよりビジネスローンをお申込されたお客様
※お電話にてお申込みされたお客様は対象となりません
項目：
法人または個人事業主： 名称、住所、メールアドレス、売上高、売上原価、借入状況、法人口座（銀行名・支店名・口座番号・名義）等
代表者： 氏名、住所、電話番号、生年月日、居住状況、世帯人数、借入状況、勤続年数、運転免許証番号、個人口座（銀行名・支店名・口座番号・名義）、年収等
保証人： 氏名、住所、電話番号、生年月日、居住状況、世帯人数、勤務先（名称、住所、電話番号）、運転免許証番号等
融資希望： 金額、開始日、期間、返済方法、資金使途、利率、審査結果等
※お客様によって、入力情報は異なります。
可能性があった期間： 2016年1月15日（金）-2020年11月26日（木）
可能性があった最大の法人・個人事業主数： 15,415件（うち、現時点でアクセスが確認された件数： 304件）
※詳細については以下のリンク先もご参照ください。
https://www.rakuten-card.co.jp/info/news/20201225/
楽天Ｅｄｙ株式会社： 故障した端末の残高移行サービス（注）申込者情報
項目： 氏名、故障端末の電話番号、Ｅｄｙ番号等
※お客様によって、入力情報は異なります。
対象となる端末とサービス申請期間：
- 「おサイフケータイ®」機能付き携帯電話 2010年10月1日(金) -2019年3月4 日(月)
- docomo select「おサイフケータイ® ジャケット01」 2014年10月30日(木) -2020年11月18日（水）
- ソニー製ハイブリッド型スマートウォッチ「wena™ wrist」シリーズの一部 2016年3月24日(木) -2020年11月18日（水）
可能性があった期間： 2016年1月15日（金）-2020年11月26日（木）
可能性があった最大の申込者数： 89,141件(うち、現時点でアクセスが確認された件数： 102件)
※詳細については以下のリンク先もご参照ください。
https://edy.rakuten.co.jp/company/press/2020/1225_notice/
（注）Ｅｄｙレスキューサービス
(公式発表より引用）
関連情報を調べている中で、Salesforce側のリリース内容に「痺れました」。どうやら今回の件は「免責」と断言できる様です。
このたび、当社の一部製品または機能（Experience Cloud〔旧 Community Cloud〕、Salesforceサイト、Site.com）を利用されているお客様において、お客様の利用するSalesforce上の組織の一部の情報が第三者から閲覧できる事象が発生しているとの報告をお客様からいただきました。
本件は、当社製品の脆弱性に起因するものではなく、ゲストユーザに対する情報の共有に関する設定が適切に行われていない場合に発生する事象であることが確認されています。ゲストユーザに対する共有に関する設定がお客様の用途に沿った設定になっているかどうかはお客様にご確認いただく必要がございます。
（SalesForceリリース内容より引用）
この設定ミスに関係しそうなSalesforceのヘルプは以下の辺りかと思います。
■ゲストユーザープロファイルを構成する際のベストプラクティスと考慮事項
Help | Training | Salesforce
共有設定
セキュアなゲストユーザレコードアクセスの設定は、ゲストユーザがあなたの組織のデータを持っていることを可視化し、アクセスを制限します。
（中略）
この設定を有効にすると、ゲストユーザーは次のことを行います。
すべてのオブジェクトについて、組織全体のデフォルトをプライベートに設定します。このアクセスレベルは変更できません。
キューまたはパブリックグループに追加することはできません。
手動共有またはApex管理共有を介してレコードへのアクセスを許可することはできません。
ゲストユーザー共有ルールを介してのみ、レコードへの読み取り専用アクセスを許可できます。ゲストユーザー共有ルールは、特別なタイプの基準ベースの共有ルールであり、オブジェクトごとに50の基準ベースの共有ルールの制限にカウントされます。
（SalesForceHelpより引用）※機械翻訳
本来はこのゲストユーザーに対するセキュリティ設定がデフォルトでONになっているべきなのかと思いますが、恐らく被害を受けた楽天グループ3社は、このセキュリティ機能が実装される前からSalesforceを利用していた為に、設定が外れていた状態だったのではないでしょうか。
このページにはもう１つ重要な事が書かれていました。「免責」だったのは、ユーザー規約や、こうした（ゲストユーザーに対する情報共有設定に関する）記述に拠るものと推測します。
警告
ゲストユーザー共有ルールタイプは、ログイン資格情報なしでゲストユーザーにアクセスを許可します。ゲストユーザー共有ルールを作成することにより、共有ルールの基準に一致するすべてのレコードへの即時かつ無制限のアクセスを誰にでも許可できます。Salesforceデータを保護し、コミュニティのゲストユーザーが必要なものにアクセスできるようにするには、このタイプの共有ルールを作成することのすべてのユースケースと影響を考慮してください。データの機密性に適していると思われるセキュリティ制御を実装します。Salesforceは、デフォルト設定からのこの変更に基づいて、認証されていないユーザーにデータが公開されることについて責任を負いません。
（SalesForceHelpより引用）※機械翻訳
上記は、色々怪しそうな所を探して見つけたヘルプページですので、もっと良いヘルプページ（リリースノート）があるのかも知れませんが、楽天のインシデント受けて各社が（自社は大丈夫か・・・と）点検すべき部分は、この辺りかと思います。
※Salesforceの12/25リリースでは、（必要な情報が書かれているので随時）リリースノートを見ろと書かれているのですが、今回の事件にかかわるノートがどれなのか、私は分かりませんでした。やや不親切な気がします。
※ほぼ同じ内容が、別なヘルプページも書かれていましたので、こちらも参考にされると良いかも知れません。
■ゲストユーザの共有設定とレコードアクセスの保護
Help | Training | Salesforce
もう１つ今回の事件に関係しそうな Salesforceの説明ページ（英語）を見つけました。これを読むと楽天グループが設定ミスをした（であろう）内容について、2018年9月には脆弱性をユーザーに告知していた事が分かります。
※侵害の可能性がある期間は、楽天が2016年~、楽天カードが2013年~、楽天Edyが2010年~となっていましたので既存ユーザーとしてこうしたクラウドサービス事業者のアラートに対する確認不足だったのかと思います。
長くなりますが、多くの方にとって参考となりそうな気がしますので、機械翻訳で全文を転記します。
■Salesforceサイトおよびコミュニティに対するセキュリティの脆弱性の影響
Help | Training | Salesforce
ナレッジ記事番号
000312863
説明
2018年9月22日、Salesforceセキュリティチームは、ゲストユーザーアクセスで発生した問題の調査において顧客の支援を開始しました。（ゲストユーザーは認証されていないユーザーです。認証されたポータルおよびコミュニティユーザーはゲストユーザーではなく、この問題の影響を受けませんでした。）
2018年10月1日、セキュリティチームは、問題がSalesforceサイトおよびコミュニティのデフォルトのゲストユーザー権限に関連していると判断しました。これにより、認証されていないゲストユーザーが、AccountオブジェクトやContactオブジェクトなどのSalesforceレコードの情報を取得できる可能性があります。
解決 2018年10月3日、Salesforceテクノロジーチームは脆弱性を修正するために次のアクションを実行しました。
1.ゲストユーザーがアクセスすることを意図していないサイトおよびコミュニティ上の特定のURLパスへのゲストユーザーアクセスをブロックするソフトウェア修正を実装しました。この更新により、ゲストユーザーは承認されたログインページに移動するか、「アクセスが不十分です」というエラーメッセージを受け取るようになります。
2. 10月3日以降に作成されたサイトまたはコミュニティの場合、Salesforce Technologyチームは、サイトおよびコミュニティの作成プロセスを更新して、新しいゲストユーザープロファイルがデフォルトでより制限された権限に設定されるようにしました。
3. 2018年10月3日より前に作成されたサイトまたはコミュニティの場合、保護の追加レイヤーを提供するために、Salesforceテクノロジーチームは、サイトまたはコミュニティの作成時にデフォルトで付与されていた標準のゲストユーザー権限を積極的に取り消しました。これらの権限は、重要な更新「ゲストユーザーのレコードアクセスの制限」がすべての顧客にプッシュされた2018年10月5日に取り消され 、顧客のデータ安全性の層が追加されました。（このアクションは、従来のSite.com製品のカスタムゲストプロファイルにも適用されます。）
これらの権限を取り消したため、一部のお客様は、サイトまたはコミュニティ内で機能上の問題が発生する可能性があります。重要な更新「ゲストユーザーのレコードアクセスを制限する」を確認して確認してから、サイト詳細ページ のパブリックアクセス設定またはコミュニティビルダーのコミュニティのゲストユーザープロファイル 設定を使用して、ゲストユーザーのアクセス権を確認することをお勧めします。特に、各ゲストユーザープロファイルの「標準オブジェクト権限」を確認して、誤ってアクセスが許可されていないことを確認することをお勧めします。一部の管理者はこれらの権限を意図的に設定している場合がありますが、これらの設定の使用に関連するリスクを理解してもらいたいと考えています。
また、Salesforceサイトのパブリックアクセス設定を読むことをお勧めします少なくとも読み取りアクセスを許可しているオブジェクトのプライベート外部ユーザー共有の使用に関する記事。ゲストユーザーのオブジェクト権限の可視性を向上させるために、ポータルヘルスチェックレポートにゲストユーザー情報を追加しました。
お客様への潜在的な影響を調査し続けていますが、この脆弱性が悪意のある活動を引き起こしたという証拠はありません。
この問題の結果としてご不便をおかけしましたことをお詫び申し上げます。
（Salesforce記事より引用）※機械翻訳
意図的に（権限を持つ）ゲストユーザーを利用しているユーザーがあるので、Salesforce側としては告知、注意喚起を出した上で、自己責任で・・としていた部分に脆弱性（設定ミス）があった、今回の楽天グループのインシデントの背景にはそうした状況があった様に思います。
余談ですが、同様な事例は「Amazon S3（AWS）の意図しない情報公開」として一昨年まで海外企業を中心としたインシデント発表をよく見かけた気がします。
AWSは以前から警告を発している - Fox on Security
Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして | Amazon Web Services ブログ
現在はほとんどAWSの設定ミスに関するインシデントを聞きませんが、これはAWSが（あまりにユーザーの管理状態が酷いので）Amazon S3パケット許可表示が一覧で見れる機能を追加した事も大きい気がします。
※図はAWSブログ記事から引用
Salesforceでもこうした視認性の高いセキュリティ機能設定ページがあれば・・・と思わなくもありませんが、リリース内容を見る限り、Salesforceもできる事はやっていた様ですので、今回のインシデントの原因は楽天側の（確認）ミスなのかと思います。
言い方を変えれば「楽天」でもミスをする、クラウドサービス利用では他社でもこうした設定ミスが十分に起こりえるだけに、改めて多くの企業にとって”良い教訓”となるかと思います。
楽天の方のお話を何度も聞いた事があり、セキュリティ対策では頑張っている企業であるのを知っているだけに、残念なインシデント発表でした。
本日もご来訪ありがとうございました。
Thank you for your visit. Let me know your thoughts in the comments.
更新履歴
