Add internal domains to SaaS Security API to determine
if an asset is being shared externally with an untrusted user.
One of the first things you need to do is
to define your internal domains. SaaS Security API uses the list
of internal domains you define to determine if the Collaborators on
an asset are internal to your company, or if the asset shared with
external users. SaaS Security API determines this by matching the
domain name in a collaborator’s email address against the list of
internal domains defined. Depending on your policy rules, SaaS Security
API identifies an asset as an incident if shared with external users.
trusted collaborator overrides
untrusted domains. Similarly, an untrusted collaborator overrides
a trusted domain. For example, you might determine that there is
no business reason to trust a file modification from
SaaS Security API uses the internal domains list to determine the Exposure
Level of an asset during the scan process, you must define
your internal domains list
you begin scanning your
cloud apps. Additionally, you can build in flexibility when you
define your internal domains:
of wildcard (*.<domain>) is supported.
—You do not need to explicitly
list subdomains; instead, use a wildcard (*.<domain>).
you modify the internal domains list, consider that you might need
to update the exposure, depending on the discovery state for a given
Rescan required to update exposure?
Existing, discovered assets
Yes. Rescan to enable
SaaS Security API to recalculate exposure.
Future, undiscovered assets
No. SaaS Security API automatically recalculates
The Internal Domains list applies to all
cloud apps on SaaS Security API so you must be an administrator
with a Super User role or an Admin role with access to All Apps
to modify this setting.