AWS amazonq high security documentation change
Summary
Expanded documentation about Slack ACL handling, including identity crawling details, permission inheritance rules, mapping logic, and failure handling for access control synchronization
Security assessment
Adds explicit details about access control mechanisms including fail-close policy to prevent unauthorized access, ACL inheritance rules, and permission enforcement - all directly related to security controls
Diff
diff --git a/amazonq/latest/qbusiness-ug/slack-user-management.md b/amazonq/latest/qbusiness-ug/slack-user-management.md index 90d924dbb..279d02609 100644 --- a//amazonq/latest/qbusiness-ug/slack-user-management.md +++ b//amazonq/latest/qbusiness-ug/slack-user-management.md @@ -11 +11 @@ Amazon Q Business supports crawling ACLs for document security by default. -When you connect an Slack data source to Amazon Q Business, Amazon Q Business crawls ACL information (channel IDs) attached to a document from your Slack instance. If you choose to activate ACL crawling, this information can be used to filter chat responses to your end user's document access level. +slack organizes content into documents, which include messages, attachments, posts, snippets, thread replies, and emojis. Messages and attachments can belong to different conversation types such as direct messages (DMs), public channels, or private channels. @@ -13 +13 @@ When you connect an Slack data source to Amazon Q Business, Amazon Q Business cr -###### Note +When you connect a slack data source to Amazon Q Business, Amazon Q Business crawls ACL information (channel IDs) attached to a document from your slack instance. If you choose to activate ACL crawling, this information can be used to filter chat responses to your end user's document access level. Access Control (ACLs) in slack is managed through users and groups. @@ -15,5 +15 @@ When you connect an Slack data source to Amazon Q Business, Amazon Q Business cr -User IDs are not crawled as direct ACLs. Identity crawler fetches the user IDs for each channel. - -The Slack user IDs are mapped as follows: - - * `_user_id`—User IDs exist in Slack on messages and channels where there are set access permissions. They are mapped from the user emails as the IDs in Slack. +**Identity Crawling** : slack allows link sharing at the document level. If a document link is shared across different channels (DMs, groups, or private channels), the new channel ID is included during crawling, effectively expanding ACLs to include members of those channels. slack does not enforce explicit deny rules: public channels allow user removal but do not prevent them from rejoining, whereas private channels restrict reentry without an invitation. The minimum permission to query channel data varies: for public channels, workspace membership is sufficient, while private channels require direct membership for access. slack enforces username restrictions, supporting only lowercase letters, numbers, periods, hyphens, and underscores. This lowercase format is maintained when crawling identities. ACL mismatches can occur if case differences exist between slack usernames and identity data stored in the connector, potentially preventing access to crawled information. When a user is deactivated or deleted, they lose access to crawled data, and subsequent syncs reflect this by removing the user from ACLs. @@ -20,0 +17 @@ The Slack user IDs are mapped as follows: +**Permission Inheritance** : The slack Workspace is the top-most entity controlling access. All workspace members can access public channels by default. Public channels have no ACLs; they are accessible to all workspace members. If ACLs are disabled, all public channel content is open to everyone on Amazon Q. DMs, groups, and private channels have independent ACLs, which completely replace any parent ACLs. Private channels restrict access to invited members, including external collaborators via slack Connect. All entities inherit permissions from the parent. @@ -21,0 +19 @@ The Slack user IDs are mapped as follows: +**Mapping Rules** : slack's inheritance mapping follows its native structure without custom logic. Federated groups are treated as local upon syncing, with all members stored regardless of status. Emails, links, and other text within messages are crawled as regular strings without specific parsing. Link-sharing does not modify document ACLs: a shared link in a message is crawled as plain text rather than as an access control change. Public channels are accessible to all Amazon Q users if no ACL is applied. @@ -22,0 +21 @@ The Slack user IDs are mapped as follows: +**Failure handling** : The connector follows a fail-close approach, meaning if there are permission-related issues or API failures, affected documents are skipped from ingestion rather than being made publicly accessible. This prevents unauthorized access while maintaining data integrity.