Access Controls Policy

Effective Date: April 16, 2026  ·  Version 1.0

This Access Controls Policy describes the technical and organizational measures Emmber, Inc. (“Emmber,” “Pluse”) implements to restrict access to production systems, consumer data, and sensitive assets. Emmber, Inc. is a Delaware corporation qualified to do business in the State of Florida, which operates the Pluse platform at pluse.to. This policy supplements Section 4 (Authentication & Access Control) and Section 5 (Personnel Security) of our Information Security Policy.

1. Access Control Principles

All access controls at Pluse are governed by the following principles:

• Principle of least privilege. Every account, credential, and API token is granted only the minimum permissions necessary to perform its intended function. No default or unnecessary privileges are assigned.
• Unique identification. Every individual with access to any Pluse system has a unique account. Shared accounts are prohibited.
• Authentication before authorization. All access to production systems, databases, third-party platforms, and consumer-facing applications requires authentication before any data or functionality is accessible.
• Defense in depth. Multiple layers of access control are applied — network-level restrictions, application-level authentication, database-level permissions, and integration-level scoped tokens — so that no single control failure exposes sensitive data.
• Separation of environments. Development, configuration, and production environments are separated. Credentials and configuration for each environment are isolated and not interchangeable.

2. Unique User Accounts

All personnel with access to Pluse systems are assigned unique, individually identifiable accounts. This applies to:

Shared, generic, or group accounts are not used for any system that stores, processes, or provides access to consumer data or production infrastructure.

3. Production Server Access

3.1 SSH Key Authentication Only

Production server access is restricted to SSH public key authentication. Password-based SSH authentication is disabled at the operating system level (PasswordAuthentication no in sshd_config). This eliminates the risk of brute-force password attacks against the production server.

3.2 Key Requirements

• Algorithm: Ed25519 (preferred) or RSA 4096-bit minimum.
• Key storage: Private keys are stored only on the authorized individual’s local machine, protected by a passphrase.
• No key sharing: Each authorized individual has their own unique key pair. Private keys are never shared, transmitted, or stored in version control.

3.3 Access Scope

Production server access is limited to deployment operations (executing git pull to deploy reviewed code) and essential maintenance tasks. Direct modification of production files on the server is prohibited — all changes flow through the git-based deployment pipeline described in Section 5.

4. Database Access Controls

4.1 Role-Based Database Credentials

Database access uses dedicated application credentials scoped to the minimum necessary privileges:

4.2 Connection Restrictions

• Localhost only: The MySQL database server accepts connections only from localhost. Remote database connections are disabled at the MySQL configuration level (bind-address = 127.0.0.1).
• No default credentials: Default MySQL accounts and passwords have been removed. All database accounts use strong, randomly generated passwords (40+ characters).
• Credentials stored securely: Database credentials are stored in environment configuration files outside the web root, never hardcoded in application source code or committed to version control.

4.3 Query Security

All database queries throughout the application use parameterized prepared statements, preventing SQL injection. String concatenation into SQL queries is prohibited. Strict SQL mode is enabled to prevent silent data truncation.

5. Deployment Pipeline

5.1 Git-Based Deployment

All code changes to the production environment follow a controlled, auditable deployment pipeline:

1. Local development. Code is written and tested in a local development environment, isolated from production.
2. Code review. Changes are reviewed before being committed to the main branch of the private GitHub repository.
3. Syntax validation. PHP files are validated with php -l and JavaScript files with node -c before deployment to prevent application-breaking errors.
4. Git commit and push. Reviewed changes are committed with descriptive messages and pushed to the private GitHub repository, creating a complete audit trail.
5. SSH deployment. An authorized individual connects to the production server via SSH (key-based auth) and executes git pull to deploy the reviewed code.
6. Post-deployment verification. Critical functionality is verified after deployment.

5.2 No Direct File Uploads

Direct file uploads to the production server (via SCP, SFTP, FTP, or any other file transfer method) are prohibited. All production file changes must flow through the git-based deployment pipeline, ensuring:

• Every change is recorded in version control with full attribution
• Any change can be audited, reviewed, or rolled back
• No unreviewed code reaches production

5.3 Private Repository

The source code repository is hosted as a private repository on GitHub. Access to the repository is restricted to authorized personnel. Repository access is managed through GitHub’s team permissions and requires MFA on the GitHub account.

6. Environment Separation

6.1 Dual Configuration Architecture

Pluse uses an environment-separated configuration architecture to isolate credentials and settings:

This dual-file architecture ensures that web-accessible processes and CLI processes load configuration independently, preventing configuration leakage between contexts.

6.2 Environment File Protections

• Outside the web root: The web-facing configuration file is stored in a directory outside the web root, inaccessible via HTTP requests.
• Apache access control: .htaccess rules explicitly block HTTP access to .env files, private keys (.p8), log files, and shell scripts, returning 403 Forbidden for any direct request.
• File permissions: Configuration files are set to chmod 600 (owner read/write only), preventing access by other system users.
• Not in version control: Environment files are excluded from the git repository via .gitignore.

6.3 Development vs. Production Isolation

Development environments use separate credentials, API keys, and database instances from production. Production credentials are never used in development, and development credentials cannot access production systems.

7. Third-Party Integration Access

7.1 Principle of Least Privilege

All third-party API integrations are configured with the minimum necessary scopes and permissions:

7.2 Token Security

All third-party OAuth tokens (access tokens and refresh tokens) are encrypted at rest using AES-256-GCM before storage in the database. Tokens are decrypted only at the moment of use for API requests and are never logged, cached in plaintext, or exposed to client-side code.

7.3 Token Lifecycle

• Issuance: Tokens are obtained through standard OAuth 2.0 flows with user consent.
• Refresh: Expired access tokens are refreshed automatically using stored refresh tokens, without requiring user re-authentication.
• Revocation: When a user disconnects an integration or deletes their account, tokens are revoked with the third-party provider and permanently deleted from our database.

8. Consumer Authentication

8.1 Authentication Methods

Pluse consumers (end users of the platform) authenticate using one of the following methods before accessing any application features, including financial integrations:

8.2 Session Protection

After authentication, sessions are protected with:

• JWT bearer tokens with HMAC-SHA256 signatures and expiration claims (mobile/API)
• HttpOnly, Secure, SameSite=Lax session cookies (web)
• 2-hour inactivity timeout with session rotation
• CSRF token protection on all state-changing web requests

8.3 Financial Features Gated by Authentication

All financial integration endpoints (bank account linking, transaction sync, payment processing) require a valid authenticated session. Unauthenticated requests receive a 401 Unauthorized response. Additionally, certain financial features are gated by subscription tier authorization, requiring both authentication and an active subscription.

9. Access Review & Revocation

9.1 Periodic Review

Access privileges across all systems are reviewed:

• On personnel change: When an individual’s role changes or they depart the organization, their access is reviewed and adjusted or revoked within 24 hours.
• Annually: All access privileges are reviewed at least once per year to ensure they remain appropriate and follow the principle of least privilege.

9.2 Revocation Procedures

When access must be revoked, the following steps are taken:

1. SSH keys: The individual’s public key is removed from ~/.ssh/authorized_keys on the production server.
2. GitHub: The individual is removed from the repository and organization.
3. Third-party platforms: The individual’s account is removed or downgraded on Stripe, DigitalOcean, Plaid, Sentry, and any other platforms they had access to.
4. Database credentials: If the individual had direct database access, the associated credentials are rotated.
5. Verification: Revocation is verified by confirming the individual can no longer authenticate to any previously accessible system.

9.3 Audit Trail

Access changes are documented. Git commit history provides an immutable audit trail of who deployed what code and when. Third-party platforms maintain their own access logs. SSH access is logged by the operating system.

10. Contact

For questions about this Access Controls Policy:

• Email: support@pluse.to
• Security: legal@pluse.to

This policy is reviewed and updated at least annually, or upon any material change to access control procedures. For the complete security program, see our Information Security Policy.

Emmber, Inc. is a Delaware corporation qualified to do business in the State of Florida. The “Pluse” name and the Pluse platform are operated by Emmber, Inc.

© 2024–2026 Emmber, Inc. All rights reserved. Pluse™ and Lux™ are trademarks of Emmber, Inc.