Security practices
Infrastructure Security
How WebCastle runs and protects its cloud infrastructure on AWS, covering network security, encryption, database and storage controls, backups and monitoring.
At a glance
- AWS is the primary cloud provider; WebCastle runs no data centres of its own.
- HTTPS in transit; cloud provider managed encryption at rest.
- Databases sit in private network segments, not directly reachable publicly.
- Managed backups are in place; scheduled restoration testing is being introduced.
Overview
WebCastle hosts the applications it builds and operates on public cloud infrastructure, with Amazon Web Services as the primary provider. There is no WebCastle-owned data centre and no self-managed physical hardware serving customer workloads, so physical security, environmental controls and hardware lifecycle are inherited from the cloud provider and covered by the provider’s own audited program.
That inheritance defines the split of responsibility. The provider secures the facilities, the hypervisor and the managed service platform. WebCastle is responsible for what it configures on top: network boundaries, identity and access, encryption settings, database and storage permissions, patching of the components it operates, and the monitoring around them. This page describes the WebCastle side of that line.
Some engagements run in infrastructure the customer owns, with WebCastle administering it under the customer’s account and policies. In those cases the customer’s controls take precedence and WebCastle works within them. Where WebCastle owns the hosting, the controls below apply. Descriptions are kept at the level a customer security team needs — WebCastle does not publish addresses, hostnames, rule sets, component versions or network topology.
Hosting model
- Primary provider
- Amazon Web Services. Compute, storage, database, networking and backup are consumed as managed services rather than self-hosted equivalents.
- Physical security
- Delegated entirely to the cloud provider. WebCastle operates no data centres and holds no customer workloads on office hardware.
- Hosting region
- Agreed per engagement during onboarding, taking account of where the customer’s users are and any data residency requirement the customer states.
- Tenancy
- Customer applications are deployed into separate environments with separate credentials. Where a customer requires account-level isolation, that is arranged as part of the engagement.
- Customer-owned infrastructure
- Where the customer owns the cloud account, WebCastle administers it under the customer’s policies, and the customer’s own security controls and provider agreements apply.
- Other providers
- A small number of supporting services — such as email delivery and content distribution — are provided by third parties. These are listed on the subprocessors page.
Infrastructure controls
Statuses reflect the current state. Where a control depends on the cloud provider, that is stated rather than presented as a WebCastle capability.
Cloud infrastructure
EstablishedWebCastle uses Amazon Web Services as its primary cloud infrastructure provider. WebCastle operates no data centres of its own, so physical and environmental security is inherited from the provider.
- Compute, storage, database and networking services are consumed as managed cloud services.
- Some engagements run in infrastructure the customer owns and WebCastle administers; in those cases the customer’s own provider and controls apply.
- The hosting region for each application is agreed with the customer during onboarding.
Encryption in transit
EstablishedTraffic to WebCastle-managed web and API endpoints is served over HTTPS, with certificates managed through the hosting platform and renewed automatically. Administrative access to infrastructure uses encrypted protocols.
Encryption at rest
EstablishedManaged databases, storage volumes and object storage use cloud provider managed encryption. Keys are held and rotated by the provider key management service rather than by WebCastle.
- Encryption is enabled at the point a storage or database resource is created.
- WebCastle does not publish algorithm or key-length detail; the implementation is the provider’s.
Backups
EstablishedManaged database backups run through the cloud provider’s native backup capabilities. Backups inherit the encryption of the service that produces them and are stored by the provider.
- Backup scope, retention and restoration expectations are agreed per engagement rather than published as a single figure.
- Application code is held in version control and is recoverable independently of infrastructure backups.
Network security
OperatingCloud provider network controls restrict inbound traffic to the ports and sources each service requires, and application and database tiers are separated so that data services are not directly reachable from the internet. WebCastle is standardising these configurations into a reviewed baseline applied across every environment.
- Databases and internal services sit in private network segments without public addresses.
- Administrative access paths are restricted rather than open to the internet at large.
- A documented network baseline and a periodic review of its configuration are being introduced.
Infrastructure access
OperatingAccess to cloud consoles and production infrastructure is held by a limited number of senior technical staff using individual accounts with multi-factor authentication. A documented review cycle over those entitlements is being formalized.
- Provider root and organisation-owner accounts are protected and are not used for routine work.
- Access is revoked as part of offboarding; evidencing that removal per system is being formalized.
Database security
OperatingDatabases run as managed cloud services in private network segments, reachable only from the application tier and from approved administrative paths. Application accounts are scoped to the database they serve.
- Database credentials are supplied through environment configuration and are not shared between environments.
- Consistent use of provider-native database audit logging is being established across all projects.
Storage security
OperatingObject storage buckets and volumes are created private by default and access is granted through cloud provider permissions rather than public exposure. WebCastle is adding an explicit check for unintended public access to its pre-release process.
- User-uploaded content is served through the application or time-limited signed links where the design allows it.
- A recurring review of storage permissions across all accounts is being introduced.
Infrastructure patching
OperatingManaged services are patched by the cloud provider under its maintenance process. Components WebCastle operates directly are updated by the responsible technical lead, prioritising issues that affect production or are externally reachable.
- Provider maintenance windows for managed services are scheduled with the customer where downtime is involved.
- A documented patch cadence with recorded outcomes is being established.
Monitoring and logging
In practiceCloud provider native metrics, availability checks and audit logs are in place for production services, and alerts route to the responsible technical team. Monitoring is performed during working hours; WebCastle does not operate a 24/7 security operations centre and does not claim continuous security monitoring.
- Provider audit logging records administrative actions on infrastructure.
- Alerting today is oriented to availability and error conditions rather than security event detection.
- Centralised log aggregation with defined retention and security alerting is the next step.
Backup restoration testing
In practiceRestores have been performed as part of migrations and environment rebuilds, which exercises the mechanism. A scheduled restoration test with a recorded result is being introduced so that recoverability can be evidenced rather than assumed.
Infrastructure as code and change management
Under EvaluationWebCastle is assessing defining infrastructure declaratively so that environments are reproducible and changes are reviewed like application code. Infrastructure changes are currently made by named administrators through the provider console and tooling.
Network security
Described generically. WebCastle does not publish rule sets, addresses or topology.
Inbound exposure
Only the services that must be public are public — typically the application’s web and API endpoints over HTTPS. Everything else is reachable only from within the environment or from approved administrative paths.
Segmentation
Application and data tiers are separated. Databases, caches and internal services run in private network segments without public addresses, and accept connections only from the application tier.
Provider network controls
Cloud provider firewalling restricts traffic by port and source for each service. WebCastle is standardising these configurations into a reviewed baseline so that every new environment starts from the same position rather than being configured case by case.
Administrative paths
Administrative access to infrastructure is authenticated, encrypted and restricted to a limited group. It is not exposed as an open service on the public internet.
Edge protection
Cloud provider baseline protections apply at the network edge. Managed web application firewall and DDoS mitigation services are being evaluated per application; where a customer requires them today they can be provisioned as part of the engagement.
Environment boundaries
Development, staging and production are separated at the infrastructure level, with distinct credentials and network configuration, so that a lower environment cannot reach production data services.
Encryption summary
| Layer | Approach | Status |
|---|---|---|
| Data in transit — public endpoints | HTTPS on WebCastle-managed web and API endpoints, with platform-managed certificates and automatic renewal | Implemented |
| Data in transit — administrative access | Encrypted protocols for console and server administration; no unencrypted administrative access | Implemented |
| Data in transit — internal service traffic | Provider-supported encrypted connections between application and managed data services; coverage is being confirmed service by service | In progress |
| Data at rest — managed databases | Cloud provider managed encryption enabled at resource creation | Implemented |
| Data at rest — object and block storage | Cloud provider managed encryption on buckets and volumes | Implemented |
| Backups | Backups inherit the encryption of the managed service that produces them | Implemented |
| Key management | Keys held and rotated by the provider key management service; a documented WebCastle key handling standard is being drafted | In progress |
WebCastle does not publish algorithm or key-length detail. Encryption is provided by cloud provider managed services and follows the provider’s published implementations.
Monitoring and logging
Production services are monitored using cloud provider native metrics, health checks and audit logs. Alerts on availability and error conditions route to the technical team responsible for the affected application, and the provider audit log records administrative actions taken against infrastructure.
WebCastle is direct about the limits of this. Monitoring is reviewed during working hours by the responsible engineering team. WebCastle does not operate a security operations centre, does not provide 24/7 security monitoring, and does not run intrusion detection or security information and event management tooling as an established capability. Alerting today is oriented to service availability rather than to detecting a security event in progress.
The work underway is centralised log aggregation across environments, with defined retention and a small set of security-relevant alerts — failed administrative authentication, permission changes, and unexpected changes to network or storage configuration. Progress is reflected in the monitoring control status above.
Backups and recoverability
Managed backups
Database backups run through the cloud provider’s native backup capabilities for the managed services in use, and are stored and encrypted by the provider.
Scope and retention
Backup scope and retention are set per engagement to match the application and the customer’s requirements. WebCastle does not publish a single frequency or retention figure, because a single figure would not be true across engagements.
Code and configuration
Application source is held in version control and is recoverable independently of infrastructure backups. Reproducible infrastructure configuration is being evaluated so that environments can be rebuilt as reliably as code can be restored.
Restoration testing
Restores are exercised in practice during migrations and environment rebuilds. A scheduled restoration test with a recorded result is being introduced so that recoverability can be evidenced.
Recovery objectives
WebCastle does not publish recovery time or recovery point objectives, because it has not yet tested against them. Where an engagement requires committed targets, they are discussed and agreed contractually rather than assumed from this page.