Post

Security Baseline for Public-Facing Internal Business Applications

SOP for securing internally built, public-facing apps

Posted Updated
By Trever Ehrfurth
10 min read
Security Baseline for Public-Facing Internal Business Applications

Overview

This SOP establishes the minimum and recommended security controls for internally-developed, publicly-facing business applications that provide value to internal employees and authorized external partners (e.g., clients). These applications integrate with sensitive data sources including HubSpot (CRM), Snowflake (analytics database), Bullhorn (ATS), and AI/LLM services (OpenAI) to support business operations and workflows.

This SOP is opinionated for the current Azure + OpenAI stack and assumes a “moderate‑impact” level for these applications.

1. Purpose and Scope

1.1 Scope

This SOP applies to:

  • Any new web application, chatbot, or public API that touches sensitive internal or client data.
  • Data flows involving HubSpot, Snowflake, Bullhorn, Matillion DPC, and external AI providers.

Out of scope:

  • The SaaS platforms themselves (HubSpot, Snowflake, Bullhorn).
  • Internal-only tools not exposed to the internet.
  • Endpoints (laptops, mobiles), which are covered by separate policies.

1.2 Data Classification

Applications in scope are treated as Moderate-Impact when they:

  • Store or process PII for employees, candidates, or customers.
  • Access financial or operational data (pipeline, compensation, revenue).
  • Trigger external communications (emails, workflow actions).
  • Allow access to external parties (clients, partners, contractors).

All in-scope apps are Moderate-Impact by default unless the Security Owner formally reclassifies them in writing.

2. Identity, Authentication, and Access Control

2.1 Licensing and Assumptions

This SOP assumes Microsoft Entra ID with P1 features:

  • Conditional Access is used to require MFA for all users and apply static conditions (location, device, blocking legacy auth).
  • Risk-based Conditional Access policies (using “user risk” or “sign-in risk”) are not required in this baseline.
  • Identity threat detection and response (ITDR) tooling (e.g., Huntress) and our MSP handle detection of suspicious identity activity and account takeover and can disable accounts or escalate incidents.

P2 may be added later for built-in risk-based policies, but is not required to meet this SOP because ITDR covers risky sign-in detection.

2.2 Authentication Requirements

All user access to in-scope apps must use Entra SSO with MFA:

  • Each app is registered as an Enterprise Application in Entra ID.
  • Assignment required is enabled; no “Everyone” or anonymous access.
  • Only modern auth (OIDC/SAML) is allowed; legacy auth is blocked.
  • A Conditional Access policy enforces MFA for all standard users accessing cloud apps.

Accepted MFA methods:

  • Microsoft Authenticator app (push or code).
  • FIDO2 security keys (preferred for admins).
  • Phone sign-in via Authenticator.
  • Temporary Access Pass for break-glass, documented and monitored.

Prohibited:

  • Password-only sign-ins.
  • Basic, NTLM, or other legacy protocols.
  • Local app-specific credentials without Entra backing.

2.3 Session Management

Sessions are enforced by your application using Entra tokens (recommended) or server-side sessions:

  • Token-based (recommended):
    • User authenticates with Entra.
    • Your backend validates Entra-issued access/ID tokens on each request (signature, expiry, audience).
    • Expired or invalid tokens are rejected; user is redirected to sign in again.
  • Session-based (if framework requires it):
    • Backend creates a session entry and sets a secure, HttpOnly cookie with a session ID.
    • Cookie uses SameSite=Strict where compatible.
    • Logout deletes the server-side session, not just the cookie.

Entra issues tokens; your app is responsible for validating them and enforcing timeouts or logout behavior.

Session defaults:

  • 8 hours max for standard users.
  • 4 hours max for admin or data-access roles.
  • Re-authentication required after privilege changes (e.g., user becomes admin).

2.4 Authorization and RBAC

Use Entra security groups mapped to app roles:

  • Example groups: SG-AppName-Users, SG-AppName-Admins, SG-AppName-DataAccess, SG-AppName-AuditOnly.
  • Map each group to app roles (Standard, Admin, DataAccess, ReadOnly) and enforce in backend APIs.

Least privilege:

  • Users see only data they need (e.g., their own deals, territory-specific candidates).
  • Bulk edits, data exports, and client communications are restricted to specific roles and may require additional approvals.

Periodic review:

  • At least annually, audit group membership and app roles, focusing on admin and service accounts.
  • Remove inactive users and document decisions for audits.

3. Hosting and Network

3.1 Azure Hosting

Preferred hosting:

  • Azure Static Web Apps for static frontends (e.g., docs, dashboards).
  • Azure App Service for APIs and dynamic services.
  • Azure VMs + Docker for special cases (e.g., NGINX Proxy Manager, legacy workloads), hardened with OS patching, NSGs, and limited management access.

All public endpoints must:

  • Enforce HTTPS
  • Redirect HTTP → HTTPS.
  • Use certificates from Azure or trusted public Certificate Authorities.

3.2 Network Segmentation and NSGs

Use NSGs on subnets/VMs:

  • Inbound:
    • Allow 443 from Internet for public-facing services.
    • Optionally allow 80 only for redirect.
    • Allow SSH/RDP only from a hardened management subnet or fixed admin IPs; deny from Internet.
  • Outbound:
    • Allow 443 to required external APIs (OpenAI, HubSpot, Bullhorn, Snowflake endpoints).
    • Block unnecessary outbound ports and destinations.

Prefer private endpoints or service endpoints for internal Azure services (databases, storage) to keep traffic off the public internet.

4. Secrets and Configuration Management

4.1 Azure Key Vault

All secrets must live in Key Vault:

  • Separate vaults per environment (kv-sai-dev, kv-sai-prod, etc.).
  • Use RBAC for access (Key Vault Secrets User, Administrator); avoid legacy access policies.
  • Use Managed Identity for services to fetch secrets without embedded credentials.

Secrets include:

  • Snowflake credentials.
  • HubSpot and Bullhorn API keys.
  • OpenAI keys.
  • Database connection strings.
  • JWT signing keys and any other sensitive tokens.

No secrets in git, Dockerfiles, NGINX configs, or plaintext config files.

4.2 Secret Rotation

  • Rotate at least annually and on staff departure or suspected compromise.
  • Maintain a checklist: generate new secret → add new version in Key Vault → deploy app with new secret → revoke old secret in source system.

5. Data Access: Snowflake, HubSpot, Bullhorn, Matillion

5.1 Snowflake

  • Define roles per app (e.g., sai_app_read) with USAGE on needed warehouses and SELECT on specific schemas/tables only.
  • Provide separate ETL roles for Matillion that can write to staging but not analytics or production tables.
  • Plan for row-level / column-level security for higher maturity.

5.2 HubSpot and Bullhorn

  • Use dedicated private apps/integrations per environment and per consuming app, not shared global keys.
  • Grant only required scopes (e.g., crm.objects.deals.read instead of full CRM admin).
  • Store keys in Key Vault; do not reuse between dev, test, and prod.

5.3 Matillion DPC

  • Use dedicated service accounts for ETL access to HubSpot/Bullhorn and Snowflake.
  • Monitor job runs and maintain logs of what data is moved and when.

6. AI / OpenAI Integration

6.1 AI Gateway Service

All AI calls (e.g., to OpenAI) should go through a central “AI gateway” service per app rather than calling the AI provider directly from the frontend or scattered backend code.

The AI gateway:

  • Validates the current user’s identity and roles using Entra ID before any data retrieval or action.
  • Enforces which tools/capabilities the AI is allowed to use (e.g., search/summarize vs update/delete vs send email).
  • Applies human-in-the-loop approval rules for high-risk actions.
  • Logs prompts, tool calls, parameters, and results for audit and incident response.

Use of an AI gateway is mandatory for any AI feature that writes or changes data (Snowflake, HubSpot, Bullhorn, internal databases), sends external communications (emails, messages), or performs actions across multiple systems.

For purely read-only AI features (summarization, Q&A over data the user can already see), an AI gateway is strongly recommended to keep identity checks, authorization, and logging consistent, but may be phased in as the platform matures.

6.2 Capability Restrictions and Approvals

Define:

  • Allowed (auto-execute):
    • Read/summarize deals, candidates, notes.
    • Draft emails/messages for user review.
  • High-risk (must be approved):
    • Bulk updates and mass changes.
    • Sending outbound emails.
    • Changing financial or sensitive fields.
    • Deleting records, changing permissions.

The app must:

  1. Show high-risk actions as a “pending suggestion.”
  2. Require explicit user approval (click or workflow) before executing.
  3. Record who approved and when, in an audit log.

6.3 Data Minimization and Vendor Terms

  • Send only required fields to OpenAI; prefer IDs over full names where possible.
  • Avoid sending secrets, passwords, or highly sensitive fields unless explicitly approved and justified.
  • Ensure vendor terms disable training on your data and limit retention and region appropriately.

When in doubt, assume model outputs may be logged by the vendor for a short period; design prompts and payloads accordingly.

7. Application Security (OWASP ASVS Level 1)

7.1 Input Validation and Output Encoding

  • Validate all inputs server-side (including from AI tools), with length, type, and format checks.
  • Use parameterized queries / ORM for DB access; never build SQL via string concatenation.
  • Encode outputs for HTML/JS/URLs to prevent XSS; rely on framework defaults (React, .NET, etc.) where possible.

7.2 Authentication and Session

  • Use Entra tokens or secure session cookies; no custom-auth unless justified.
  • Invalidate sessions on logout and after privilege changes.
  • Do not expose tokens in URLs or logs.

7.3 API Security

  • All APIs that touch sensitive data require authentication (Entra OAuth/OIDC, API keys, or mTLS).
  • Apply rate limiting and CORS whitelisting; avoid * for origins.
  • Consider Azure API Management for key APIs to centralize policies.

8. Logging, Monitoring, and Incident Response

8.1 Centralized Logging

Log and centralize:

  • Entra sign-ins and Conditional Access results.
  • Azure resource activity and diagnostics.
  • Application logs (auth, access, errors, AI actions).
  • Snowflake, HubSpot, Bullhorn, OpenAI usage (where available).

Send to a central Log Analytics workspace or SIEM with at least 1-year retention for security logs.

8.2 Alerts

Configure alerts for:

  • Repeated failed logins or unexpected sign-in patterns.
  • Unusual API usage (e.g., 10x normal volume).
  • Abnormal AI usage (e.g., many high-risk action suggestions).

Identity-based threat detections (e.g., stolen sessions, suspicious logins) are primarily surfaced and acted upon by ITDR tooling and your MSP, which can disable accounts and drive response.

8.3 Incident Response

Maintain simple runbooks for:

  • Account compromise: disable account, rotate secrets, review logs, notify affected users.
  • API key/secret exposure: revoke keys, search code and logs, rotate credentials, and update Key Vault.
  • AI misbehavior: disable AI feature, inspect prompts and actions, revert bad changes, and tighten capabilities or approvals.

Run at least one tabletop exercise per year that includes an AI-related incident (e.g., mass email or bulk update gone wrong).

9. SDLC, Testing, and Change Management

9.1 Secure SDLC

  • Create a simple threat model diagram for each new app or major feature.
  • Require peer review for all changes, using a security checklist (secrets, auth, input validation, logging).
  • Document how the app uses Entra, Snowflake, HubSpot, Bullhorn, Matillion, and OpenAI, etc.

9.2 Automated Security Testing

  • Use SAST and dependency scanning in CI (e.g., GitHub Advanced Security, Snyk, SonarQube).
  • Run DAST or targeted security scans before major releases.

9.3 Environment Separation

  • Separate dev/test/prod environments with different Key Vaults and secrets.
  • Restrict production access, require approvals for production deployments.

10. Governance, Training, and Review

10.1 Exceptions

  • Document any deviations from this SOP (e.g., legacy systems) with compensating controls and an expiry date.
  • Review exceptions quarterly.

10.2 Training

  • Developers: annual training on OWASP Top 10, ASVS Level 1, and secure use of Entra, Key Vault, Snowflake, and AI tools.
  • Users: onboarding materials for MFA, phishing, and safe use of SAI and other AI tools.

10.3 Annual Security Review

Annually, for each in-scope app, verify:

  • Entra SSO + MFA via Conditional Access are enforced.
  • Secrets live in Key Vault and are rotated per policy.
  • Data access is least-privilege across Snowflake, HubSpot, Bullhorn.
  • AI actions are constrained and logged.
  • Logging, alerting, and IR playbooks exist and have been exercised.

Treat this SOP as a living document; update it as maturity grows (e.g., add row-level security, formal pen testing, or Entra P2 risk-based controls later).

SOPs, Security
azure entra apps security sop
This post is licensed under CC BY 4.0 by the author.