Article body
Full article
Enterprise BI platforms carry the most critical business data. Security is not an add-on feature—it is part of the product’s DNA. Hengshi HENGSHI SENSE builds a five-layer defense-in-depth system spanning authentication, authorization, data masking, auditing, and physical isolation. This article dissects each layer with actionable security best practices.
I. Why Enterprise BI Security Is a “System,” Not a “Feature”
A typical enterprise BI security requirement spans multiple dimensions: who can log in (authentication—password, MFA, SSO, OAuth), what they can see after logging in (functional and data permissions), whether the data they see is masked (field-level masking and row-level filtering), who did what and when (audit logs), whether data is safe after leaving the platform (export controls, watermarks, encryption), whether model inference exposes data (AI inference security, core requirement: data never leaves the domain), and whether the platform itself is attack-resistant (network security and API security). A weakness in any single point can bring down the entire security posture. What enterprises need is not “a few security features” but a defense-in-depth system.
II. Hengshi’s Five-Layer Security Architecture
Hengshi’s security architecture is divided into five layers from outside in.
The outermost layer (Layer 5) is Physical Security, delivered by HENGSHI BOX, ensuring data never leaves the box, network isolation, and local inference. Layer 4 is Audit Trail, covering full operation logs, change tracking, and compliance reports. Layer 3 is Data Security, including Row-Level Security (RLS), column-level masking, data export controls, and watermarks. Layer 2 is Access Control, based on an RBAC role model with App-level isolation and resource-level fine-grained authorization. The innermost layer (Layer 1) is Identity Authentication, supporting SSO, OAuth, OIDC, MFA, API Key, and Keyring token management.
III. Layer 1: Identity Authentication
Hengshi supports mainstream enterprise authentication protocols. Username/password fits on-premises deployments and small teams with low configuration complexity. OAuth 2.0 is suitable for ISV product integration with moderate complexity. OIDC fits modern identity providers. SAML 2.0 fits enterprise unified SSO with higher complexity. API Key suits Agents, CI, and automation scenarios. LDAP or AD fits enterprise domain controllers.
Keyring Token Management is an important but often overlooked security design detail. The CLI’s authentication token is not written to a local config file but goes into the operating system’s Keyring—macOS Keychain, Linux Secret Service, or Windows Credential Manager. This means even if an Agent’s runtime environment is compromised, an attacker cannot directly read plaintext tokens from a config file. To steal credentials, they would need to breach OS-level security mechanisms.
API Key Management allows creating API Keys for CI/CD and Agent access with a reasonable expiration period (recommended: 90 days). An API Key is displayed only once after creation and must be stored securely afterward. Key rotation is supported—new keys replace old ones, with a 24-hour grace period where the old key remains valid to avoid service disruption during the switch.
IV. Layer 2: Access Control
Hengshi provides a four-tier built-in role system. Admin has platform-wide management privileges, typically for IT administrators. Editor has creation and editing permissions within an App, typically for data analysts. Viewer has read-only access within an App, typically for business users. Custom supports custom permission combinations for users with special requirements.
Multi-level authorization granularity, from coarse to fine: App-level authorization (grants access to an entire application space), dataset-level authorization (grants editing or viewing permissions to a specific dataset), dashboard-level authorization (grants access to a specific dashboard), and chart-element-level authorization (grants viewing access to individual charts—the finest granularity).
User Group Management reduces administrative complexity. After creating a user group, add members in bulk and authorize at the group level. For example, create a “East China Sales Manager” group, add relevant members, then grant editor permissions at the group level with data filtering conditions (can only see East China data).
Permission inheritance follows clear conflict resolution rules: explicit deny overrides explicit allow, user-level permissions take precedence over group-level permissions, and fine-grained permissions take precedence over coarse-grained permissions. This system ensures predictable permission behavior—no more “I set permissions but they don’t seem to work” confusion.
V. Layer 3: Data Security
Row-Level Security (RLS) ensures users can only see the rows of data they are authorized to access. Row-level filtering rules can be set, such as filtering by region (users can only see data for their region) or by department (users can only see data for their department). RLS policies are defined at the dataset level, and all dashboards and reports using that dataset automatically inherit them.
Column-Level Data Masking protects sensitive fields. Phone numbers can be masked (showing the first three and last four digits, with the middle four as asterisks). ID numbers can be partially masked (keeping the first and last digit). Masking rules are configured at the dataset level and take effect universally.
Data Export Control limits the risk of data leaving the platform. You can set the maximum number of rows per export, whether approval is required, and whether watermarks are automatically added. Watermark traceability allows configuring watermark content (such as username and timestamp), watermark transparency (e.g., 0.1, ensuring it doesn’t interfere with reading but remains traceable), and watermark position (e.g., diagonal arrangement), effectively preventing screenshot leaks.
VI. Layer 4: Audit Trail
Full Operation Logs record every action any user performs on the platform. You can filter and query by time range, user, and operation type. Logs include timestamp, username, operation type, operation object, and other key information. Audit reports can be exported (e.g., monthly compliance report in PDF format).
Change Tracking records the change history of each dashboard and dataset, showing who made what modifications and when. All operations performed by Agents via CLI also enter the audit log with an Agent source marker, making it easy to distinguish human from automated operations.
VII. Layer 5: Physical Security (HENGSHI BOX)
HENGSHI BOX provides the highest level of data security assurance. The user browser connects via HTTPS to the enterprise intranet gateway (VPN optional), then accesses the BOX through the intranet. The BOX contains a database and local models—all data queries and model inference are completed inside the BOX. Network isolation between the public internet and the BOX ensures data does not pass through external networks.
The BOX’s security compliance check can generate a one-click security status report, including network isolation status, whether data exfiltration is blocked, whether model inference is local-only, storage encryption method (AES-256), transmission encryption method (TLS 1.3), audit log status, and compliance status (data resides within the box, GDPR-ready, China’s Personal Information Protection Law-ready).
VIII. Security Best Practices Checklist
Authentication: Enable SSO or OAuth instead of default passwords, set reasonable API Key expiration (recommended 90 days), use Keyring for credential management and prohibit plaintext storage, rotate API Keys and service account credentials regularly.
Permissions: Follow the principle of least privilege, authorize user groups rather than individual users, regularly review the permission matrix to clean up stale permissions, have all permission changes go through a dry-run confirmation.
Data: Configure column-level masking for sensitive fields, configure row-level filtering rules for all datasets, limit the volume and frequency of data exports, automatically add watermarks to exported files.
Auditing: Enable full operation logs, set up alerts for anomalous behavior (e.g., large-volume data exports), generate and archive monthly audit reports, bring Agent operations into the audit scope.
IX. FAQ
Q1: How large is the security difference between HENGSHI BOX and cloud deployment?
The BOX’s physical isolation means data never passes through the public internet, and large model inference is also completed locally—making it suitable for scenarios with extremely high requirements for data sovereignty (finance, government, military). While cloud deployment supports encrypted transmission and storage, data remains logically in the cloud environment.
Q2: Can the dry-run mechanism completely prevent Agent misoperations?
Dry-run ensures there is a reviewable output before changes are made, but it relies on human review. If an approver clicks “approve” without carefully reviewing, dry-run is just for show. For high-risk operations (such as deleting datasets or modifying permissions), we recommend setting up multi-person approval.
Q3: How long are audit logs retained?
The default is 180 days, which can be extended via administrator configuration. For scenarios with higher compliance requirements, we recommend regularly exporting audit logs to an independent log storage system.
Conclusion
Hengshi’s security architecture reflects a key insight: security is not “adding one wall,” but “having walls at every layer.” From details like Keyring token management to HENGSHI BOX’s physical isolation, every layer provides a safety net for data security. For ISV vendors and enterprise IT teams, understanding this five-layer defense-in-depth system is a prerequisite for building a trustworthy BI platform.