Network hardening & private deployment

StrataBI deploys into your AWS account, so network posture is yours to own. The base deployment aims to be a clean, working starting point — not a finished security architecture for every organization. This page describes what the deployment gives you by default, the hardening patterns teams commonly layer on, and where that work starts to depend on decisions only your organization can make.

What the base deployment provides

Out of the box, the Terraform module stands up the application on ECS Fargate behind an Application Load Balancer, with a few network controls you can turn on without touching the module internals:

• TLS on the load balancer. Provide an ACM certificate ARN and the module adds an HTTPS (:443) listener and redirects :80 to it.
• Ingress allow-listing. Restrict which CIDRs may reach the load balancer. A common use is to put a CDN or proxy (for example Cloudflare) in front and allow only its published ranges, so the origin can't be reached directly.
• Host pinning. When TLS and a published hostname are configured, the listener will only serve requests whose Host header matches that hostname; other requests (including direct-to-IP probes) get a 403.
• Bring-your-own authentication. The app recognizes an already-authenticated user from a trusted header, so it sits behind your identity provider or auth proxy rather than managing its own logins. See Authentication & SSO. Authorization is then handled by role-based access control.

That combination — private-by-CDN origin, TLS, host pinning, IdP in front, RBAC behind — is enough for many teams. See the Security posture page for the application-level controls.

Patterns teams layer on

Beyond the base, organizations with stricter requirements typically add some of the following. These are not shipped as defaults, because the right choice depends on your existing network, identity, and compliance setup:

• Private subnets, no public load balancer. Run the service on an internal ALB in private subnets with a NAT gateway for egress, reachable only from inside your network.
• Identity-aware access at the edge. Enforce authentication before traffic reaches the app — an ALB authentication action against your OIDC/SAML IdP, an identity-aware proxy, or a reverse proxy that validates against Active Directory / your SSO.
• Private connectivity. Reach the service over PrivateLink, Transit Gateway, VPN, or Direct Connect instead of the public internet; use VPC endpoints for the AWS services the app and its modules call.
• Segmentation. Dedicated subnets and security-group boundaries between the load balancer, the application tasks, and any module Lambdas or data stores.
• Corporate WAF / proxy. Front the origin with your own WAF, egress proxy, or CDN and lock the origin to it.
• Administrative access via SSM rather than a bastion, so there's no standing SSH path.

Why the base product stops here

These patterns are genuinely variable: a team on a single account with an IdP has very different needs from one with a hub-and-spoke network, air-gapped subnets, and an AD forest. Trying to encode every option into the base module would make it brittle and opinionated in ways that fight real environments. StrataBI instead keeps the base small and composable — it runs cleanly inside your network design rather than imposing one.

If you'd like help mapping StrataBI onto a hardened layout for your environment — private connectivity, identity-aware access, segmentation, and the rest — Shaleio can advise and suggest reference layouts. Get in touch.