MFAによるランサムウェア対策

IPA（独立行政法人情報処理推進機構）は、その年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から脅威候補を選出し、情報セキュリティ分野の有識者が審議・投票を行い決定したものを「情報セキュリティ 10大脅威」として公開しています。2021年度、「ランサムウェアによる被害」が昨年５位から１位にランクを上げて注目を浴びています。（出典：IPA(情報処理推進機構) 情報セキュリティ 10大脅威 2021 組織別順位・2021年8月23日）​ランサムウェアとは、マルウェアの一種です。特徴は、ランサムウェアに感染したコンピュータは、利用者のシステムへのアクセスを制限されてしまう。（暗号化、ロックなど）この制限を解除するための身代金を要求すること。身代金を払うことでその制限を解除するという犯罪に利用される。​日本国内でもランサムウェアによる被害が多数報告されています。2021年7月、ランサムウェアによる攻撃を受け、財務/販売管理の基幹システムやファイルサーバ、グループネットワークで運用していた販売管理システムや財務会計システムが暗号化された事例がありました。この事例で特徴的なのは、BCP（事業継続計画）として用意していたバックアップサーバも暗号化されて、業務復旧までに想定以上の時間を要し、四半期決算報告を延期せざるをえない結果となった点です。​同様に、10大脅威の3位にランキングしている「テレワーク等のニューノーマルな働き方を狙った攻撃」、8位の「インターネット上のサービスへの不正ログイン」に関しても、ランサムウェアによる攻撃につながる脅威として対応が求められます。​ランサムウェア対策の一つとして、MFA（多要素認証）を活用してユーザ認証を実施することにより、情報漏洩リスクを低減することが可能です。​コロナウイルス禍の影響で、ニューノーマルと言われる、クラウドシフトした業務システムの利用やリモートワークのような働き方改革が一般的になりました。ただ、企業のセキュリティ対策が、この変化に対応が取れていないのが現状です。従来のセキュリティ対策は、社員がオフィスへ出社し、イントラネットワークからアクセスすることを想定したものでした。ファイアウォールによって社内ネットワークをインターネットから切り離し、社外からのアクセスをチェックしていた境界防御です。ニューノーマルにおいては、境界をまたぐ形で社員からのアクセスや業務システムへの通信が発生し、外と内に分ける考え方では制御しきれない状況となりました。​ランサムウェアによる攻撃の例として、悪意の第三者が社内ネットワークにリモートからVPN接続するために必要なIDとパスワードを詐取した場合、従来型のセキュリティ対策ではプロアクティブに犯行を発見/防止することが困難です。社内ネットワークへ侵入した悪意の第三者は、正規ユーザとして社内の重要な資産にアクセスが可能で、その制御や発見するすべもありません。インターネットサービスの利用に関しては、企業内部からのアクセスを許可するIPアドレス制限をかけていたとしても、社内ネットワーク経由の接続は全て許可され、本人確認のチェックが効きません。詐取されたIDとパスワードを利用し、インターネットサービス上の業務システムから重要情報を取得し、社外へ持ち出されてしまいます。​ランサムウェア対策としてMFAを活用する背景には、ゼロトラストという「誰も信用しない」という考え方に基づき、ユーザを認証して社内外のアクセスをコントロールする必要性があるからです。全てのユーザはMFAという「関所」にアクセスし、認証された結果に応じて適切なアクセス権を付与されます。また、必要なタイミングでアクセス権を確認し、ユーザのコントロールと可視化をMFAは実現できます。​セールスフォース社の場合、全社員がVPN経由で社内ネットワークにアクセスする際、IDとパスワード以外にMFAによる認証が求められます。社内ネットワーク接続後も、重要な社内情報を閲覧する際にもMFAによる認証を求められ、アクセス権を有する社員かどうかをチェックする体制を取っております。​2022年2月1日から、セールスフォース社はサービスログイン時にMFAによる認証を必須とします。この背景には、上述のゼロトラストの思想より、ランサムウェアによる攻撃を防止することにあります。​インターネット上のサービスへの不正アクセスへの対策としてMFAが有効なのは、ゼロトラストの観点から、IDやパスワードでチェックするだけではなく、ユーザ個人が有するデバイスを活用して多面的に認証をかける点にあります。アクセス元のIPアドレスの制御に加えて、アクセスを試みたユーザが本人なのか、接続するたびにチェックをかけることによって、情報漏洩のリスクを軽減することが可能となります。​​

CRM Analytics ダッシュボードサンプル集

本ページでは、CRM Analyticsのダッシュボードの例をいくつかご紹介いたします。マーケティング分析、営業の成績比較、活動・商談・問い合わせ分析、地図分析、不動産・中古物件販売分析、顧客ターゲティング

確認したい指標を決めよう

要件定義の整理方法誰が、どの状況で、何の示唆を得るためのダッシュボードかを定義するまずはじめに、これから作成しようとしているダッシュボードの目的を決めましょう。具体的には、以下の3点について考えます。

CRM Analytics ドリル

CRM Analyticsのダッシュボードを作成するには、機能を理解し、実践あるのみ！ダッシュボードの各種機能をマスターできるドリルをご用意しました。CRM Analyticsの機能を知って、ぜひダッシュボードを構築してみてください。

エキスパートから学ぶ

エキスパートコーチングとはエキスパートコーチング「ダッシュボード作成入門」についてエキスパートコーチングの申込方法エキスパートコーチングとはエキスパートコーチング・セッションは、お客様がSalesforceの製品からより多くの価値を得られるようにデザインされた専門的なコーチング・プログラムです。

<応用編>TheModelダッシュボードを作成してみよう

本記事で構築手順を公開している「The Model ダッシュボード」とは、各KPI（リード数、商談数、受注数）をリアルタイムに確認し、様々な軸で分析することで、PDCAサイクルを高速に回すことができるダッシュボードです。

CRM Analytics ホームの操作方法

CRM Analytics のホーム画面の操作方法ホーム画面の構成ここではCRM Analyticsの基本設定終了後に表示される「Analytics Studio」をクリックするとまず最初に表示されるホーム画面についてご紹介致します。

基本用語を理解しよう

CRM Analyticsのデータ環境とアーキテクチャCRM Analyticsでのダッシュボード構築の流れはじめに主要用語ヘルプ「Analytics の用語集」アプリケーション データセット、レンズ、ダッシュボードのグルー プを含む動的な「フォルダ」のことで、同僚との共有が可能(アプリケーションごとに共有範囲の 設定が可能)

CRM Analytics を有効化しよう

CRM Analytics の利用開始において必要な設定方法はじめにCRM Analytics にアクセスするためには権限セットが必要で、権限セットを付与するためには権限セットライセンスが必要です。権限セットは2種類用意されております。

CRM Analytics を知ろう

この章では、CRM Analyticsの活用を開始するにあたり、最初に知っておいていただきたい内容を記載しています。CRM Analyticsとは？CRM Analyticsとは、AIを搭載したSalesforceの分析プラットフォームです。 Salesforceと直接連携し、現状や過去の経緯をもとにした分析だけでなく、将来の結果を予測し、ビジネスにおいて次の行動を考える手助けをします。

住宅販売の営業マンがSalesforce導入リーダーになったら。定着化までの奮闘記：株式会社アイダ設計事例

住宅販売の営業マンがSalesforce導入リーダーになったら。定着化までの奮闘記失注商談をインサイドセールスが引き受け、復活商談として掘り起こして店舗へとつなぐ失注リサイクルについてSalesforceの標準機能を用いて構築した事例についてお話しいただきます。また、Account Engagement (旧 Pardot)のEngagement Studioを活用した ”シナリオに沿ったメール送信の自動化とお客様ごとに表示するコンテンツを動的に切り替えるダイナミックコンテンツ” による近隣店舗へのお客様誘導を実現したエピソードもお届けします。https://play.vidyard.com/7qZjv9Xa6EaMydS7X8RNBdSFUG TrailblazerウェブセミナーとはNTTテクノクロス株式会社 鈴木様が司会を務めるウェブセミナーです。​毎回、テーマに応じたTrailblazerの方をゲストスピーカーとしてお迎えし、Salesforceの活用経験談や、困難を乗り越えた秘訣などをお話いただきます。

組織の体制変更がある場合の対応のポイント

この記事で学べることSalesforce稼働後の（自社の）組織体制変更時の対応の流れを知ることができます組織体制変更時に使用するツールについて知ることができます組織体制変更時の対応の流れSalesforceのシステム管理者のみなさまは、普段新入社員のユーザを作成したり、退職するユーザを無効化したり、ユーザ情報の更新（部署やロール、プロファイルの変更）等のユーザ管理業務を行なわれていると思います。※ ユーザの管理については「ユーザ管理の便利機能」も参考にしてください。​今回は、期初や期末にみなさまの会社で行われる事があるであろう、組織の体制変更に伴い、Salesforceにどのような変更を行う必要があるかを考慮点含めて説明します。※人事異動の場合はユーザ情報の更新（ロール項目の変更）になりますが、今回はロール自体を変更する場合の作業の流れになります​一般的に、組織の体制変更がある場合、以下のような変更が行われると思います。それをSalesforceに反映させるための変更箇所は以下のとおりです。組織の変更に伴う変更点Salesforceの設定変更箇所組織の体制変更（新たな部署が設置される/既存の部署が統合されるなど）・ロール（自体）の変更・階層構造の変更既存の部門/部署名の変更・ロール（の名称）変更・ユーザの[部署名]の変更部署のメンバーの変更・ユーザの[ロール]の変更役職名の変更・ユーザの[役職]の変更お客様の担当替え・取引先や商談の[所有者]変更・活動の[任命先]変更注意事項：上記以外にも、例えば[ロール名]を条件にしたレポート、ダッシュボード、数式項目、フロー等の自動化設定がある場合は、それらの変更も忘れずに実施しましょうユーザの[ロール]や[役職]項目以外にも、プロファイル、マネージャーや権限セットの変更が必要な場合は一緒に変更しますSalesforceの設定変更箇所を把握したので、「早めに変更作業をしたい」と思うかもしれませんが、その前に！決めておくべきことがあります。移行ルール変更作業に着手する前に、関連部署のメンバーとあらかじめ以下を決めておくことで、変更作業をスムーズに進めることができます。組織の体制変更後に、Salesforceのデータをどのようなルールで共有するか（データへのアクセス権をどうするか）最終的に、どのようなロール階層にするか共有ルールを使用するか、使用する場合にはどのようなルールにするか誰がどの取引先を担当するか取引先の新旧担当者一覧の作成商談の担当はどうするか例：現在進行中の商談の担当者は変更しない、完了している商談の担当は変更しない（過去の実績を組織の体制変更前の担当で把握する必要がある場合は、担当者を変更しないでください）活動の担当はどうするか例：まだ完了していない活動の任命先を変更するか/しないか注意事項：上記以外のオブジェクトを使用している場合は、オブジェクト毎に担当をどのようにするかを決めておきましょう。​移行ルールが決まったら、次の流れで変更作業を行いますロール・共有ルールの変更ユーザ情報の変更各データの所有者変更１．ロール・共有ルールの変更まずは組織の土台となるロール、およびロールを使用した共有ルール（アクセス権）の設定を行います。ロールや共有ルールは、2.ユーザ情報の変更作業が完了するまでは反映されません。そのため、ユーザ情報変更作業前に、あらかじめ準備をしておきます。​組織の体制変更後の状態に合わせて、ロールを変更します。新たな部署が追加される場合は、[ロールの追加]からロールを作成します部署が統合される場合も、新たな部署を作成します。統合前の部署を残しておくと、退職したユーザのロールを変更する必要がありません​階層構造の変更はなく単なる名称変更の場合は、[表示ラベル]と[レポートに表示するロール名]を変更します階層構造が変わる場合は、[このロールの上位ロール]項目を変更します会社の合併など、大幅な組織体制変更の場合は、新しいロール階層を定義することをお勧めします。​組織の体制変更の前日までは、旧体制のまま業務を行う必要があると思いますので、あらかじめ新組織体制の準備でロールを作成しておき、新組織体制に変わるタイミングでユーザ情報を更新して新しいロール設定を反映させます。​次に、ユーザ情報を変更して、新しい組織体制を反映させましょう。２．ユーザ情報の変更組織の土台となるロールおよび共有ルールの設定が終わったら、ユーザ情報の変更を行います。​ユーザ情報は、以下3種類の方法で変更することができます。ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面から複数ユーザを一括で変更するデータローダを使用する​ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面の[ユーザをロールに割り当て]で、複数ユーザを一括で変更する（具体的な操作手順は、「ユーザへのロールの割り当て」（ヘルプ）をご覧ください）​データローダを使用する​組織の体制変更がある場合、一般的には、ロールを変更するタイミングでプロファイルや部署名、役職名等も変更になることがあると思いますので、それらを一度に変更ができるデータローダを使用することをお勧めします。（データローダの使い方ついては「初めてのデータローダ 〜Update編〜」（サクセスナビ）をご覧ください）​注意点：承認プロセスにマネージャー項目を使用している場合は、マネージャー項目も忘れずに変更しましょう。​ユーザ情報の変更が完了したら、取引先や商談などのデータを変更します。３．各データの所有者変更事前に定義した移行ルールに従い、データの所有者（や任命先）を変更します。​所有者の変更は、画面上から行える「所有権の一括変更」もしくはデータローダをご利用いただけます。どちらのツールが適しているかは、以下をご確認ください。​注意点：「所有者の一括変更」機能を利用できるのは、リード、取引先、カスタムオブジェクトのみです上記フロー以外のデータ（例：現在の所有者が所有している完了している商談など）の扱いについては、オプションで選択をすることができます。​以上で、組織の体制変更があった場合に、システム管理者様にて対応が必要な作業は完了です。学習ツールロールの項目（ヘルプ）ユーザの項目（ヘルプ）データの所有権の移行（ヘルプ）取引先の一括変更で、同時に移行されるデータについて（ナレッジ）まとめ変更作業を始める前に、移行ルールを決めておくことが重要ですデータ変更に使用できるツールは「所有権の一括変更」とデータローダがありますので、要件にあう方を選択しましょう