HubSpotのセキュリティは、HubSpotが担うサービス基盤の保護と、自社が「設定」で決めるログイン・権限・同意の管理に分けて考えます。自社側の設定は、歯車アイコンの「設定」にある「Security」(2要素認証・SSO・ログイン制限)、「Users & Teams」(権限セット)、「Privacy & Consent」(データプライバシー設定・Cookie同意バナー)、「Account Management」の「Audit Logs」(監査ログ)が中心です。本記事は法的助言ではなく、公式ナレッジと設定画面の名称に沿った実務の整理です。
「顧客データをクラウドCRMに預けるのが心配」 「GDPRや個人情報保護法への対応で、何から整えればよいかわからない」 「Excelの顧客一覧とHubSpotの登録情報がずれて、誰がどのデータを扱うか追いにくい」——こうした悩みは、HubSpotの導入時にも運用中にも起こります。
最初に顧客データの取得元、利用先、担当者を書き出してください。その流れに沿って認証、権限、同意の記録、操作履歴を確認すると、設定を変える前に解決すべき問題が見えてきます。GDPRや日本の個人情報保護法に関わる判断では、HubSpot上の設定に加え、社内で定める利用目的やデータの扱いも確認します。
この分野の体系的な情報はHubSpot機能ガイド でまとめています。 本記事は「HubSpot初期設定・オンボーディング完全マニュアル|アカウント作成後にやるべき設定一覧 」シリーズの一部です。 本記事はStartLinkの「HubSpot完全ガイド 」関連記事です。
この記事でわかること
HubSpotの導入を担当する方や、既存アカウントの権限・同意管理を見直す方に向けて、確認する順序を整理します。読み終えると、2要素認証・SSO・権限セット・Cookie同意バナー・監査ログのそれぞれについて、設定画面の場所、必要なプラン、自社で決めることが分かり、最初の1週間の進め方まで決められます。
セキュリティ機能の全体像 — サービス基盤の資料で確認する項目と、自社アカウントで決める認証・権限を分けて整理します。
ログインとアクセス制御 — 二要素認証を確認し、社内のID管理と接続経路からSSO・IP制限の必要性を判断します。
プライバシーとCookie同意 — 取得時の説明、訪問者の選択、フォームの記録、配信対象を実際の操作で照合します。
監査ログと継続的な見直し — 追いたい操作を確認できるか調べ、権限変更や退職時の対応に結び付けます。
プラン選定の観点 — 必要な統制を先に定め、契約中の機能と現行の提供条件を照合します。
HubSpotのセキュリティは基盤とアカウント運用で考える
検討の出発点は、「HubSpotのサービスについて確認すること」と「自社で決めること」を分けることです。
StartLinkでは、この整理を「基盤・アカウント・同意」の3層チェックとして使っています。基盤はHubSpotが担う層、アカウントは認証・権限・監査ログを自社が設定する層、同意はフォーム・Cookie・配信で本人の選択を記録する層です。層ごとに「誰が決めるか」「どの画面で確認するか」「何を試せば完了と言えるか」を1行ずつ書き出すと、抜けが見えます。なお、HubSpotの設定だけでGDPRや個人情報保護法への対応が完結するわけではなく、利用目的の特定や委託先の管理など、社内の規程で決める部分が残ります。
サービス基盤の資料を確認しても、営業担当者が閲覧できるレコードや、取得したメールアドレスの利用目的は決まりません。データの登録、利用、削除に関わる担当者を定め、それぞれの段階に設定と確認方法を対応させます。
プラットフォームの対策と自社設定を切り分ける
サービス基盤については、まず自社の審査で必要な条件を挙げます。次に、その条件を判断するための資料と、適用される契約文書を確認してください。資料で確認できた条件、自社の運用で決める条件、追加の照会が必要な条件を分けて記録します。
次の表は、審査で確認する表現を洗い出すために使います。各行を自社の採用条件と照合し、暗号化や第三者監査は対象と根拠資料を、法令への対応はサービス側の資料と自社の取扱いを、サービス水準は適用される契約文書を確認してください。
確認項目
HubSpot公式ページで確認できる内容
審査での扱い
通信の暗号化
ログインやAPI呼び出しなどの通信はTLS 1.2または1.3を使用
自社の要件(TLSバージョン等)と照合
保存データの暗号化
サーバーのドライブや長期保管ストレージはAES-256で暗号化
対象範囲を公式ページで確認
SOC 3/SOC 2 Type 2
SOC 3は公開レポート、SOC 2 Type 2は機密扱いでTrust Centerから顧客・検討者が入手
社内審査にはTrust Centerのレポートを使用
ISO 27001
公式ページ上は、HubSpotが利用するクラウド基盤事業者がSOC 2 Type 2とISO 27001の認証を保有(HubSpot自身の認証とは書かれていません)
「HubSpot自身が取得」と書かずに、保有主体を確認して記録
GDPR
認証ではなく、GDPR削除、適法な処理の根拠(legal basis)・同意の記録、Cookie同意バナーなどの機能を提供
機能の設定は自社で行い、適用の判断は法務担当者へ
データの保管場所
米国東部のAWSが基本。ドイツ・フランクフルトのEUデータセンターに保管することも選択可能(新規顧客向け)
データ所在地の要件があれば契約前に確認
稼働率
公式ページでは月間稼働率99.95%に向けた商業上合理的な努力を記載(Product Specific Termsの該当条項)
具体的な保証内容は契約文書で確認
これらは、HubSpotのセキュリティページ(Trust Centerへの案内を含む) で確認した内容です。更新されることがあるため、審査の時点で最新を確認してください。「GDPR準拠」という表現を確認するときは、サービスについて示されている内容と、自社が決める取得目的や利用方法を分けます。可用性を審査するときは、まず停止時に影響を受ける業務と必要な復旧条件を整理します。そのうえで、契約文書の対象サービス、測定条件、例外、対応内容が自社の条件に合うか確認してください。判断に必要な条件が見つからなければ照会先を決め、その回答を受けて導入判断を進めます。
審査でよく聞かれる認証・暗号化・GDPRの3点
HubSpotはISO 27001やSOC 2の認証を取得していますか? HubSpotのセキュリティページ では、SOC 3が公開レポート、SOC 2 Type 2が機密扱いのレポートとしてTrust Centerから入手できると案内されています。ISO 27001とSOC 2 Type 2は、HubSpotが利用するクラウド基盤事業者が保有する認証として記載されており、HubSpot自身の認証とは書かれていません。社内審査では、Trust Centerのレポートと、この記載の区別を記録してください。
HubSpotのデータは暗号化されていますか? 公式のセキュリティページでは、ログインやAPI呼び出しなどの通信にTLS 1.2または1.3、保存データにAES-256を使うと記載されています。ただし、これは基盤側の対策です。誰がどのレコードを見られるかは、自社の権限設定で決めます。
HubSpotでGDPR対応のために最初に設定するものは何ですか? 「Privacy & Consent」の「Data privacy settings」をオンにし、Cookie同意バナー、フォームのデータプライバシー欄、コンタクトのlegal basis(適法な処理の根拠)の記録を確認します。どの根拠を選ぶかは法務の判断事項のため、社内の法務担当者や専門家と決めてください。
サービス基盤の確認と並行して、自社で決める範囲を次の表で整理します。資料で通信の保護を確認できても、誰に顧客情報の閲覧を認めるかは自社で判断します。
管理の範囲
確認する内容
自社で決めること
HubSpotのサービス基盤
通信・保存データの保護、サービス運用に関する公開情報
自社の要件に対して資料が足りているか
アカウント
認証方式、ユーザー権限、監査ログ
誰に何のアクセスを認めるか
Webサイト・配信
Cookie同意、配信カテゴリ、データ処理の根拠
目的の説明、同意取得、配信対象の管理
資料の確認を待つ項目にも、必要な資料、照会先、判断する担当者を記録します。一方、利用者と担当業務が明確な権限設定は実際のアカウントで試せます。何を確認できれば次へ進めるかを項目ごとに決めておくと、資料の確認と運用の整備を並行して進められます。
顧客データの流れを先に書き出す
フォームから入った情報をコンタクトに登録し、会社や取引に関連付け、営業活動やメール配信に使う場合を考えます。取得元ごとに、取得時の説明、利用目的、閲覧者、利用先、削除依頼の窓口を並べてください。同じコンタクトでも、登録経路が違えば確認すべき説明や記録が異なります。
次に、表計算ファイルや手作業のメールにも同じ情報があるか調べます。取得時の説明と配信対象が一致しなければ、配信設定より先に対象データの扱いを決めます。閲覧者を特定できなければ、権限設定を先に見直します。登録元と利用先、判断する担当者を説明できるようになったら、それぞれの場面に必要な機能を選びます。
公式資料で確認する仕様
二要素認証の設定を始める際は、HubSpotで二要素認証をセットアップする を参照し、利用中の画面に表示される方法と対象条件を確認してください。社内向けの手順には、実際に選べる方法、設定を確認する担当者、ログインできない場合の連絡先を記録します。画面と社内手順が食い違う場合は、適用前に手順を更新します。
アカウント設定画面で同意を管理する
以下の画面は、HubSpotのデータプライバシーと同意の設定画面です。画面を開く前に、フォームで示す利用目的、保存したい選択の記録、メール配信への利用を整理してください。そのうえで、利用中のアカウントのどの設定が各項目に対応するか調べます。設定項目が見つからない場合は、説明文や運用方法を決める担当者と確認し、記録を残せる方法が定まってから取得と利用の流れを試します。
二要素認証でHubSpotへのログインを守る
二要素認証(2FA)は、パスワードに加えて別の認証要素を求める仕組みです。最初に管理者と代表利用者が設定し、実際にログインできるか試します。アカウント全体に要求する前に、未設定者への案内、ログインできない場合の問い合わせ先、対応する管理者を決めてください。
ユーザー自身で設定する手順
公式ナレッジSet up two-factor authentication for your HubSpot login では、Starter・Professional・Enterpriseのアカウントで、ユーザー名とパスワードでログインするユーザーに2要素認証が必須とされています(無料ツールのアカウントは任意)。設定の場所と認証方法は次のとおりです。
画面上部の設定(歯車)アイコンをクリックします。
左サイドバーの「General」>「Security」を開きます。
「Two-factor authentication (2FA)」セクションで設定を開始します。
認証方法(パスキー、認証アプリ、SMS)から選びます。SMSは安全性が最も低いとされ、パスキーや認証アプリが推奨されています。
表示された手順でコードを入力し、バックアップコードを保存します。
セカンダリの方法も追加し、ログイン時の確認頻度(Remember meは28日間、またはAsk every time)を選びます。
完了表示と実際のログイン結果を分けて確認します。ログインできない人がいれば、どの段階で止まるかと連絡先を記録し、対応後に再度試してください。対象者がログインできることを確認してから、次の適用範囲を決めます。
管理者がアカウント全体に要求する
Super Adminまたは「Edit account defaults」権限を持つユーザーは、「設定」>「Security」>「Login」タブの「Enforce 2FA to log in」をオンにして、アカウント全体に要求できます。有効化から24時間後に適用され、個別のユーザーを除外することはできません。未設定のユーザーには、「Security」>「Permissions」の画面からリマインダーを送れます。適用前に、管理者自身がログインできること、問い合わせ先が決まっていることを確かめます。
ログインの仕組みを人に依存させない
利用開始時には設定方法を案内し、管理者が完了状況を確認します。異動や退職の連絡を受けたら、認証状態とアクセス権を一緒に見直します。担当者が変わっても同じ判断ができるよう、確認する人、記録する場所、問題が見つかったときの連絡先を決めておきます。
ログインできる人を確認したら、その人が閲覧・変更できるデータを担当業務と照らし合わせます。業務に不要なアクセスがあれば権限を見直し、変更後に必要な業務を行えるか確かめてください。
SSOとIP制限は必要な統制から選ぶ
SSOを検討するときは社内のID管理方針を、IP制限を検討するときは業務に必要な接続経路を確認します。どちらも対象者、利用場所、管理者が対応する場面を書き出し、必要な統制を明確にします。その要件を、利用中の契約と現行の公式情報に照らして確認してください。
SSOの役割と導入の流れ
社内のID管理基盤でHubSpotのログインも扱う必要がある場合は、利用する接続先と設定条件を確認します。次の表から自社で使う接続先を特定し、現在の対応状況と契約上の利用条件を個別に照合してください。表中の対応状況だけを設定開始の根拠にせず、確認した条件を担当者と共有します。
IdP
公式ナレッジでの位置付け
準備のポイント
Okta
対応IdPとして記載
IdP側でHubSpot用アプリを作成
Microsoft Entra ID(旧Azure AD)
対応IdPとして記載
Azure MarketplaceのHubSpotアプリを利用
Google(Google Workspace)
対応IdPとして記載
Googleの案内に沿って設定
OneLogin
対応IdPとして記載
IdP側でHubSpot用アプリを作成
AD FS・その他SAML 2.0対応IdP
AD FSは別記事で案内。その他もSAML対応なら設定の考え方は共通
バインディングはHTTP Post、署名はSHA-256のみ、NameIDはメール形式
公式ナレッジSet up single sign-on (SSO) によると、設定にはSuper Admin権限が必要で、手順は次のとおりです。
IdP側で、HubSpot用のアプリケーションを作成します。
設定(歯車)>「Security」>「Login」タブの「Single sign-on (SSO)」で「Configure」を開きます。
フェデレーションメタデータ(XML)をアップロードするか、IdPの値を貼り付けて「Verify」で検証します。
全員に必須にする場合のみ「Require single sign-on」をオンにします。
「Manage exempted users」で対象外のユーザーを指定します。Super Adminを少なくとも1人は除外しておくことが推奨されています。
https://app.hubspot.com/login/sso にメールアドレスを入力し、IdPのログイン画面へ遷移するかを確かめます。
SSOを必須にする前に、Super Adminを1人は対象外にして 、設定の誤りでログインできなくなる事態に備えます。
SSOは2要素認証と併用できます。SSO対象外のユーザーにはHubSpotの2要素認証を必須にする、といった使い分けも公式ナレッジで案内されています。テストでは、想定する利用者がログインできるか、管理者が設定を確認できるかを見ます。ログイン後に閲覧できるCRMデータは別途ユーザー権限で確認してください。ログインできても不要なデータが見える場合は権限を見直します。利用者または管理者のログインに問題があれば、止まった画面と設定を記録し、原因を確認してから再試行します。
IP制限は社内の接続経路と合わせる
IP制限は、公式ナレッジLimit logins to trusted IP addresses に沿って、Super Adminが「設定」>「Security」>「Login」タブの「Allowed login IPs」から設定します(Starter・Professional・Enterpriseが対象)。VPNや許可範囲外のIPからのログインをブロックでき、モバイル端末にも適用されます。例外ユーザーの指定や、場所(Allowed login locations)による制限もあります。IP制限を検討するときは、オフィス、VPN、社外、モバイルからの接続を業務ごとに整理します。利用中のセキュリティ設定画面で機能と適用条件を確認し、接続元を登録する前に、管理者と代表利用者のテスト方法を決めてください。
確認項目
利用者が社内ネットワーク中心
社外・リモート接続も必要
許可する接続元
オフィスなどの利用経路を整理
VPNを含む接続経路を整理
テスト対象
管理者と代表利用者
社外・モバイルを含む利用者
判断
登録した接続元で業務が完結するなら適用を検討
必要な経路が網羅できるまで適用を保留
各業務について、誰が、どの接続元から、何をする必要があるかをテスト対象にします。管理者と代表利用者が必要な経路からアクセスできるかを確かめ、想定外の経路をどう扱うかも決めてください。試せていない経路があれば対象者とテスト方法を確認し、管理者がアクセスできなければ復旧時の連絡と設定を見直す手順を整えます。必要な経路の結果がそろってから、適用範囲を判断します。
必要な機能とプランを照合する
先に「社内のID管理とログインをそろえたい」「接続元を限定したい」などの要件を書き出します。次の表で必要な機能を選び、契約中の製品で利用できる条件と設定できる担当者を、現行の公式情報とアカウント画面で照合してください。
セキュリティ機能
公式ナレッジでの対象プラン
設定する人・場所
2要素認証(2FA)
Starter・Professional・Enterpriseはパスワードログインで必須。無料ツールは任意(管理者が必須化可)
各ユーザー/Super Adminなど。「設定」>「Security」
アカウント全体への2FA要求
公式ナレッジでは無料ツールを含む管理者設定として案内
Super Adminまたは「Edit account defaults」権限。「Security」>「Login」
SSO(シングルサインオン)
Professional・Enterprise(トライアルでも設定可)
Super Admin。「Security」>「Login」
ログインIP・場所の制限
Starter・Professional・Enterprise
Super Admin。「Security」>「Login」
監査ログ(Audit Logs)
Starter・Professional・Enterprise(Enterpriseはフィルターのカテゴリが増える)
Super Admin。「Account Management」>「Audit Logs」
権限セット
Enterprise
Super Admin。「Users & Teams」>「Permission Sets」
利用条件を照合した後は、設定担当者と導入後の確認方法を決めます。たとえばSSOなら利用者と管理者のログイン、IP制限なら必要な接続経路、監査ログなら追いたい操作を確認対象にします。条件が合わない項目は、必要な統制を満たす別の運用方法も比較し、要件と提供条件を整理してからプランを判断してください。
GDPRと個人情報保護法に沿ってデータの扱いを整える
GDPRや日本の個人情報保護法に関わる運用では、取得したデータを何に使うかを先に整理します。対象データと業務上の扱いを社内で確認し、それに対応する設定と記録方法を決めます。個別の法的判断が必要な点は法務担当者や専門家と整理してください。
データプライバシー設定で使う機能を確認する
公式ナレッジHow do I turn on GDPR functionality in my HubSpot account? によると、設定(歯車)>「Privacy & Consent」で「Data privacy settings」をオンにします(Super Adminまたは「Edit account defaults」権限が必要)。オンにすると、Cookie同意バナー、新規フォームのフッターのデータプライバシー欄、営業メール・シーケンスメールの配信停止リンクが有効になり、コンタクトのインポートや一括編集で同意情報と適法な処理の根拠(legal basis)を登録できます。legal basisの値がないコンタクトには、メールの開封・クリックのトラッキングが追加されません。EUのデータセンターのアカウントでは初期状態でオンです。
「プライバシーと同意」の設定を確認する前に、フォームで説明する利用目的、Cookieの利用、メール配信の種類、削除依頼の窓口を書き出します。そのうえで、利用中のアカウントに表示される設定項目が、自社の業務のどの段階に対応するかを確認します。
HubSpotのデータプライバシーと同意の設定画面。同意管理の設定を行えます。
確認は、テスト用の登録で取得から利用まで順に進めます。フォーム上の説明を読み、選択を変えて送信し、CRMに残る内容と配信対象を照合してください。選択に関する記録が見つからなければ、フォームと保存方法を確認します。説明した目的と配信対象が異なれば、配信設定を見直します。説明、記録、実際の利用が一致し、担当者がその結果を追える状態になってから運用を進めます。
配信カテゴリを目的ごとに設計する
送る内容ごとに、取得時の説明、コンタクトの選択、配信対象の条件を対応させます。次の表で自社の連絡を整理し、カテゴリ名だけで配信可否を決めず、フォーム送信後の記録を確認してください。
配信カテゴリ
内容
例
マーケティング情報
ニュースレター、キャンペーン
月次メルマガ
製品アップデート
新機能・リリース情報
プロダクトニュース
営業連絡
商談に関する連絡
見積もり・契約関連
イベント案内
セミナー・ウェビナー
展示会招待
配信前には、送る内容が取得時に説明した目的に含まれるか、コンタクトの選択を確認できるか、抽出条件がその記録を反映しているかを順に見ます。ある目的で取得したコンタクトを別のカテゴリで配信対象にする場合は、説明と記録を改めて照合してください。判断できないコンタクトは対象に加えず、社内の運用担当者に確認します。
削除要求はCRMの関連データまで確認する
HubSpotのコンタクト削除には、90日以内なら復元できる「Restorable delete」と、データを完全に消す「Permanent delete」があります(完全削除はデータプライバシー設定がオフでも使えます)。削除依頼を受けたら、本人確認、対象レコード、依頼の範囲を整理します。コンタクトに会社、取引、活動履歴が関連付いている場合は、各データに関わる担当者と扱いを確認してください。対象と処理方法が一致していることを確かめてから実行を判断し、確認結果を記録します。削除は元に戻せない操作になり得るため、法的な適用範囲や関連データの扱いが定まらない場合は、実行前に社内の法務担当者や専門家と整理します。
Cookie同意バナーはサイトと配信の運用につなげる
Cookie同意バナーを設定するときは、サイトで使うCookieと訪問者に示す説明を対応させます。その後、訪問者の選択がサイト上でどう反映されるかをテストします。フォームの説明やメール配信の記録も続けて確認しますが、バナーでの選択だけをメール配信についての判断材料にはしません。計測や広告を含めて確認が必要な場合は、関係する担当者とテスト範囲を決めてください。
バナーの表示内容を設定する
設定場所は、設定(歯車)>「Privacy & Consent」>「Cookies」タブです。公式ナレッジ によると、従来のバナー(v1)から新しいエディター(v2)への移行が段階的に進んでいるため、手順は新エディター用の記事 に分かれています。自社のアカウントがどちらかを先に確認してください。
バナーの種類
動き
向いている場面
Notification(通知)
Cookieを使うことを知らせるだけ
同意が不要と社内で整理した用途
Opt-in(オプトイン)
訪問者が同意するまでトラッキングを行わない(カテゴリ別の選択も可)
同意取得を前提にする運用
Opt-out(オプトアウト)
初期状態で受け入れ、バナーから拒否できる
国・地域ごとに方針を分ける運用
ドメインがHubSpotで確認済みか、または外部ドメインにトラッキングコードがあるかを確認します(新エディター)。
対象ドメインのポリシーを開き、バナーの種類、URLパス、対象国、Global Privacy Controlへの対応を設定します。
カテゴリごとのラベル・説明文・ボタンの文言を入力します(Necessaryは常に有効)。
プライバシーポリシーへのリンクを確認します。
テスト用の訪問者で各選択肢を試し、結果を確認してから公開します。
権限は、Super Adminまたはウェブサイト設定の編集権限が必要です。訪問者が拒否するとコンタクトレコードにページビューが紐付かなくなり、手動で埋め込んだスクリプトは自動ではブロックされない点にも注意してください。
公開前に、説明文がサイトでの実際の利用に合っているか、各選択肢の結果を確認できるかを調べます。説明と動作が食い違う場合は、表示文言または関連する設定を修正し、再度プレビューしてください。
Cookieの目的と選択肢を対応させる
必須、分析、広告、機能などのカテゴリについて、実際にサイトで利用するものと、その目的を照合します。続いて「同意する」「カスタマイズ」「拒否」をそれぞれ選び、各選択で想定した状態になるか確かめます。特定の選択だけを試して公開を判断せず、説明した目的と結果を選択肢ごとに比べてください。意図どおりに反映されない場合は、公開前にバナーと関連設定を見直します。
サイト、フォーム、CRMの状態をそろえる
テスト用の訪問者としてバナーを選択し、フォームを送信して、CRM内の記録とメール配信カテゴリを確認します。バナーの選択結果を確認できない場合はサイト側の設定を調べます。フォームの説明や選択が記録に反映されない場合はフォーム設定を、取得した目的と異なる配信対象になる場合は配信条件を見直します。それぞれの段階で、何を選び、どこに記録され、何に利用されたかを追える状態になってから運用を開始してください。
監査ログと権限レビューで運用を続ける
設定後は、誰がアクセスし、権限や連携がどう変わったかを確認します。まず自社で追いたい操作を決め、その操作を利用中のアカウントで確認できるか調べます。ログの確認担当者と、気になる操作を見つけたときの連絡先も定めてください。
セキュリティアクティビティーを確認する
監査ログは、Super Adminが設定(歯車)>「Account Management」>「Audit Logs」で確認します(公式ナレッジ )。ビューは「All Logs」「Login History」「Security Activity」の3種類で、表示は過去30日間です。セキュリティアクティビティ履歴のエクスポートは過去1年間を対象にできます。Starter・Professionalで選べるカテゴリはLoginとSecurity Activityのみで、Enterpriseは承認・コンテンツ・ワークフローなどのカテゴリが加わります。次のような、自社で追いたい操作を列挙し、それぞれの記録をどこで確認するか照合してください。
ログイン
設定変更
データのエクスポート
ユーザーや権限の変更
連携の接続・切断
画面で確認できない操作については、利用条件と社内の別の記録方法を調べ、確認担当者が追える手順を決めます。
操作履歴をアカウント運用に結び付ける
次のような、自社で対応が必要になる場面を挙げます。
不審なログイン
想定外のエクスポート
管理者権限の変更
退職者のアクセス
該当する操作を見つけたら、操作した利用者、業務上の理由、対応する担当者を確認します。理由が確認できれば判断を記録し、確認できなければ担当者へ連絡して権限やアクセスの扱いを見直します。確認日と対応結果を残し、次の権限レビューで参照できるようにしてください。
権限と連携先を最小限に保つ
権限は仕組みで回すのが現実的です。たとえば、四半期に1回の権限レビュー、退職・異動の連絡から翌営業日までにアカウントとSSO対象を見直す、といった基準を運用ルールとして先に書いておくと、担当者が変わっても同じ判断ができます(基準の日数は自社で決める例です)。Enterpriseでは、「Users & Teams」>「Permission Sets」から権限セットを作成できます(公式ナレッジ )。「Make Super Admin」「Start with a template」「Start from scratch」から選び、ユーザーに割り当てます。権限セットを割り当てると個別の権限は上書きされ、作成は最大100件です。Enterprise以外のプランでは、ユーザーごとの権限で、営業・マーケティングなどの職務に必要な範囲に絞ります。新しい利用者や外部連携には、担当業務に必要なアクセスを確認してから権限を付けます。異動・退職や連携停止の連絡を受けたら、対象者と関連する権限を調べます。変更後は、必要な業務を行えるかと、不要なデータへアクセスできないかを両方確認してください。想定と異なる場合は権限の範囲を調整し、再確認した結果を記録します。
段階的に整備し、必要な機能を見極める
対策の優先順位は、現在のデータの流れと管理上の不足から決めます。判断に迷うときは、次の表の「状況」から着手点を選びます。
状況
最初に確認する設定
確認の目安
パスワードだけでログインしている利用者がいる
「Security」で2要素認証(パスキー・認証アプリ)
Super Adminの2要素認証の状況と、未設定ユーザーのリマインダー
社内のID基盤でログインを一本化したい
「Security」>「Login」のSSO(Professional・Enterprise)
Super Adminを対象外にした状態で、/login/ssoからのログイン
社外からのアクセスを限定したい
「Allowed login IPs」と「Allowed login locations」
VPN・モバイルを含む必要な経路すべて
営業とマーケで見えるデータを分けたい
ユーザー権限、Enterpriseなら権限セット
変更後に、必要な業務ができ、不要なデータが見えないこと
同意の記録を追えない
「Privacy & Consent」のデータプライバシー設定とCookie同意バナー
テスト送信後のlegal basisと配信対象
誰が設定を変えたか追えない
「Account Management」>「Audit Logs」
Security Activityに追いたい操作が出るか
StartLinkのHubSpot導入・構築支援では、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の順に進め、権限設計やプライバシー設定もこの工程の中で小さく始めて広げます。HubSpotゴールドパートナーとして150社以上のHubSpot支援に携わってきた経験から、権限と同意の設計は、データ移行や外部連携の前に決めておくと後戻りが減ると考えています。支援の内容はHubSpot導入・構築支援 、連携先を含めた全体設計はHubSpot連携ガイド で紹介しています。Google WorkspaceやMicrosoft 365のアカウント基盤と合わせたログイン設計はHubSpot×Google Workspace/Microsoft365連携ガイド 、外部システムとのAPI連携の権限はHubSpot API・Webhook開発ガイド も参照してください。
利用者の本人確認が未整備なら認証から、配信目的を追えないなら取得時の説明と記録から着手します。基本的な運用を確認した後で、SSOやIP制限など追加の統制が必要か判断してください。
機能一覧を自社要件に合わせて読む
次の表から自社に必要な機能を選び、契約中の製品で使える範囲を現行の公式情報とアカウント画面で照合します。特に権限やログは、機能の有無に加え、対象となる操作やデータの範囲まで確認してください。
セキュリティ機能
Free/無料ツール・Starter
Professional・Enterprise
2要素認証(2FA)
Starterは必須、無料ツールは任意
必須(SSO必須のアカウントは例外あり)
データプライバシー設定・Cookie同意バナー
設定(歯車)>「Privacy & Consent」で設定(対象は公式ナレッジで確認)
同左
ログインIP・場所の制限
Starterから利用可
利用可
監査ログ
Starterから利用可(カテゴリはLoginとSecurity Activity)
Professionalは同左、Enterpriseはカテゴリが増加
SSO
公式ナレッジでは対象外
Professional・Enterpriseで利用可
権限セット
対象外
Enterpriseのみ
表を見る順序は、自社の要件、契約中の機能、実際に必要な設定範囲です。たとえば操作履歴が必要なら、まず追いたい操作を列挙し、その記録を利用中のアカウントで確認できるか調べます。要件を満たせると確認できた項目から設定を進め、確認できない項目は提供条件と代わりの運用方法を調べてから判断します。
まず不足している統制を特定する
現在のログイン方法、ユーザー権限、サイトの同意取得、操作履歴の確認方法を書き出します。それぞれについて「担当者を決めれば運用できるか」「現在の設定を直せば足りるか」「追加機能が必要か」を分けてください。設定で対応する項目はテスト結果まで確認します。追加機能が必要な項目は、提供条件、設定担当者、導入後の確認方法がそろってからプランを判断します。
バックアップと復元条件を確認する
バックアップ方針を決める前に、復元したいデータと、そのデータに関連する業務を挙げます。続いて、復元できる対象、条件、担当者を現在の公式情報と契約内容で確認してください。重要データをエクスポートする場合は、保存先のアクセス権、更新のタイミング、復元時の手順を決めます。必要な対象を復元できるか判断できない場合は、条件の確認を担当者に依頼し、その結果を踏まえて運用方法を決めてください。
最初の1週間で確認する順番
初めて整えるなら、次の順に進めると、ログインできなくなる事故を避けながら統制を足せます。
設定(歯車)>「Users & Teams」で、Super Adminの人数と退職者のアカウントを確認します。
「Security」で自分の2要素認証(パスキーまたは認証アプリ)を設定し、バックアップコードを保存します。
「Security」>「Login」で、全員への2要素認証の要求(Enforce 2FA to log in)を適用する日を決め、未設定者にリマインダーを送ります。
「Privacy & Consent」で、Data privacy settingsとCookie同意バナーの状態を確認します。
テスト用のフォーム送信で、同意とlegal basisがコンタクトに記録されるかを見ます。
「Account Management」>「Audit Logs」で、Login HistoryとSecurity Activityに記録が出ているかを確認します。
SSOやIP制限は、必要性が整理できてから、Super Adminを例外にした状態で設定します。
できる範囲から運用を定着させる
まず二要素認証、利用者権限、プライバシー設定の担当者と確認方法を決めます。フォームからの登録と配信、ログイン、権限変更の場面を試し、判断に必要な記録を追えるか確認してください。結果を追えなかった項目は、設定、記録方法、担当者のどこが不足しているかを分けて見直します。SSOやIP制限は、必要な統制と利用者の接続経路を説明できる状態になってから検討します。
よくある質問
この節の要点
保管場所 ── 対象データと確認資料を整理し、公式資料と契約内容で適用される条件を照合します
削除要求 ── 本人、対象レコード、依頼の範囲と関連する業務データを確認します。法令上の判断や関連データの扱いが定まらない場合は、実行前に社内の担当者や専門家と整理します
二要素認証の全員要求 ── 管理者向けの要求設定と適用条件を確認し、対象者の結果を確認してから全員への適用を判断します
SSOのプラン ── 公式ナレッジではProfessionalまたはEnterpriseが対象です。提供条件は現行の公式情報で照合します
認証・暗号化 ── SOC 2 Type 2はTrust Centerから、ISO 27001は基盤事業者の認証として記載されています
個人情報保護法への対応 ── 顧客データの取得元、利用目的、配信カテゴリ、閲覧者の整理から始めます。個別の法的判断は法務担当者や専門家に相談します
HubSpotに保存されたデータの保管場所はどこですか?
HubSpotのセキュリティページによると、基盤はAWSの米国東部リージョンでホストされ、2021年7月19日以降の新規顧客はドイツ・フランクフルトのEUデータセンターを選べます。既存顧客はデータ移行ツールで移行できます。保管場所の要件がある場合は、契約前にセキュリティページと契約文書で自社のアカウントに適用される条件を確認してください。
GDPRに基づくデータ削除要求に対応できますか?
HubSpotのコンタクト削除には、90日以内なら復元できる「Restorable delete」と、データを完全に消す「Permanent delete」があります。本人確認、対象レコード、依頼の範囲を整理し、会社・取引・活動履歴など関連データの扱いを確認してから実行してください。完全削除は元に戻せないため、法令上の判断や関連データの扱いが定まらない場合は、実行前に社内の法務担当者や専門家と整理します。
二要素認証をユーザー全員に要求できますか?
できます。Super Adminまたは「Edit account defaults」権限を持つユーザーが、設定(歯車)>「Security」>「Login」タブの「Enforce 2FA to log in」をオンにします。有効化から24時間後に適用され、個別のユーザーを除外することはできません。適用前に管理者自身のログインとバックアップコードを確認し、未設定のユーザーにはリマインダーを送ってください。
SSOはどのプランで利用できますか?
HubSpotの公式ナレッジ(Set up single sign-on)では、Marketing・Sales・Service・Data・Content・Smart CRM・Revenue Hubのいずれかの、ProfessionalまたはEnterpriseが対象とされています。トライアル中も設定できます。設定にはSuper Admin権限が必要です。導入時は、Super Adminを1人は対象外にしたうえでテストしてください。契約中のプランでの提供条件は、現行の公式情報で確認してください。
個人情報保護法への対応で、最初に何を整えますか?
まず、顧客データの取得元、利用目的、配信カテゴリ、閲覧者を整理します。次に、設定(歯車)>「Privacy & Consent」のデータプライバシー設定、Cookie同意バナー、メール配信設定が、説明した目的と一致するかテスト送信で確認します。記録と実際の利用を照合できた範囲から運用を進め、判断できないデータの利用は社内で確認してください。個別の法的判断は法務担当者や専門家に相談します。
HubSpotはISO 27001やSOC 2の認証を取得していますか?
HubSpotのセキュリティページでは、SOC 3が公開レポート、SOC 2 Type 2が機密扱いのレポートとして案内されています。ISO 27001とSOC 2 Type 2は、HubSpotが利用するクラウド基盤事業者が保有する認証として記載されており、HubSpot自身の認証とは書かれていません。社内審査では、Trust Centerのレポートとこの記載の区別を記録してください。
まとめ
HubSpotのセキュリティ運用は、顧客データの取得から利用、削除までの流れに、認証、権限、同意の記録、操作履歴を対応させて考えます。設定後は実際の登録、ログイン、配信、権限変更を試し、説明した目的と記録、実際の利用が一致するか確認してください。
HubSpotにアクセスするユーザーと、業務に必要な権限を確認します。
二要素認証とCookie・配信同意の設定を、実際の利用場面で確認します。
操作履歴から運用を見直し、不足する統制があれば必要な機能と現行の提供条件を照合します。
企業様によって最適な形は異なります。取得するデータ、利用する部署、接続経路を基に、次に整える項目を決めてください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい