Data-source security and permissions

Every connector operates inside a provider-defined authorization model: OAuth scopes, app-installation permissions, cloud roles, service principals, or API keys. The connection flow is the authoritative place to review the exact permissions requested for that provider and configuration mode.

Before connecting

1. Use a dedicated app, role, or service identity where the provider supports one.
2. Restrict the account, organization, project, site, or tenant boundary to the intended compliance scope.
3. Prefer read-only permissions and remove optional capabilities you do not intend to use.
4. Record who approved the connection, which environment it covers, and when it should be reviewed.
5. Check provider plan/API limitations that can make a nominally successful connection incomplete.

Some provider APIs bundle read access broadly. The scope a provider requires can be wider than the subset Noru's collector currently stores. Authorization means the credential could call the allowed API; it does not mean every accessible field becomes a Noru record. Review the provider-specific setup text and your own provider audit logs.

Credential lifecycle

Noru stores connector credentials for scheduled collection. Rotate or revoke them through the provider and reauthenticate the integration when necessary. Offboard the connection when its owner, system, or scope is retired. A disconnected source stops future collection, but existing evidence may remain for audit/history until your retention/deletion workflow removes it.

After connecting

• compare collected objects with the intended account boundary
• inspect unexpected evidence, assets, identities, vendors, or findings
• verify that sensitive values are not present in uploaded/manual evidence
• review the provider's audit log for connector activity
• set an owner for reauthorization and failure response
• periodically re-review scopes after provider or Noru connector changes