Security practices
Access Control
How WebCastle manages accounts, permissions and authentication across its systems, and where the access control program is still being formalized.
At a glance
- Named individual accounts; production access held by a limited technical group.
- Multi-factor authentication on cloud consoles and critical admin services.
- Access follows project assignment and is withdrawn when a person leaves.
- A documented, scheduled access review cycle is being formalized.
Overview
Access control at WebCastle covers two distinct populations. The first is the internal accounts WebCastle staff use to build, deploy and operate systems. The second is the accounts that exist inside the applications WebCastle builds for its customers. This page describes the first. Access controls inside a delivered application are agreed with the customer during the engagement and are described on the application security page.
The working principle is that access follows role and project assignment. Team members receive access to the repositories, environments and services required for the work they are assigned to, and nothing broader by default. Production access is deliberately narrow and is held by a limited number of technical personnel. Multi-factor authentication is enforced on cloud provider consoles, source control and other critical administrative services.
WebCastle is formalizing this program. Several of the practices below are applied consistently but are not yet written down as an approved standard, reviewed on a fixed cycle, or enforced from a single identity platform. Where that is the case the status says so. WebCastle publishes the current state rather than the intended one, so that a reviewer can judge the gap directly and ask about it.
Account lifecycle
How access is granted, changed and removed as people join, move and leave.
Access is scoped to the role
Before start dateThe delivery or technical lead identifies the systems the role requires, based on the projects the person will work on. Production and administrative access are not part of a standard grant; they are requested separately and approved on their own merits.
Accounts are provisioned
On joiningNamed individual accounts are created on each required system. Access is never granted by handing over an existing set of credentials. Multi-factor authentication is configured at this point on every service that supports it.
Access changes with responsibility
On role or project changeWhen someone moves between projects, access is extended to the new scope. Removing access that is no longer needed is the weakest point in the current lifecycle, and it is the specific gap the access review work is intended to close.
Departure is notified
On noticeDelivery and technical leads are notified so that project responsibilities, repository access and any credentials associated with the person can be identified before the last working day.
Access is withdrawn
On the last working dayAccounts on WebCastle-managed systems are disabled or removed. Repository, cloud console and production access is revoked, and any credential the person held that is not tied to an individual account is rotated.
Removal is confirmed
After departureThe technical lead responsible for each system confirms removal. WebCastle is turning this into a documented checklist so that completion can be evidenced system by system rather than attested informally.
Access control measures
Each control below carries an honest maturity status. "In progress" and "developing" mean the practice exists but is not yet documented, scheduled or centrally enforced.
Multi-factor authentication
EstablishedMulti-factor authentication is enforced on cloud provider consoles, source control and other critical administrative services. Extending it to every remaining business application is in progress.
- Administrative access to cloud infrastructure requires a second factor.
- Source code repository accounts require a second factor.
- Services that do not support a second factor are identified and are being replaced or restricted.
Production access
EstablishedAccess to production environments is granted to a limited number of technical personnel. Engineers working on a project do not receive production access by default.
- Production access is requested explicitly and approved by the technical lead responsible for the system.
- Access is scoped to the specific customer environment, not granted across the estate.
- Customer-owned production environments are accessed only with that customer’s authorisation.
Source code repository access
EstablishedSource code is held in version control with access restricted to the team members assigned to a project. Repositories are private and are not open to the whole company by default.
- Repository permissions follow project assignment.
- Customer code is separated by repository so that access to one engagement does not imply access to another.
Separation of production and non-production access
EstablishedDevelopment, staging and production are separate environments with separate access. Credentials that work in a development environment do not grant access to production.
Least privilege
OperatingAccess is granted to the systems a role needs rather than to everything a team can reach. WebCastle is tightening the review of long-standing accounts, where accumulated permissions are the most likely source of over-provisioning.
- New access is scoped at the point of request.
- A structured review of existing permission grants against current responsibilities is underway.
Role-based access model
OperatingAccess is assigned by role and project rather than per individual request wherever the platform supports it. A documented role-to-permission mapping covering all core systems is being written.
Account provisioning
In practiceNew team members receive named individual accounts on the systems their role requires. The request and approval trail exists in practice but is not yet recorded in a single, auditable place.
- Accounts are created per person; access is never granted by sharing an existing login.
- A central provisioning record that a reviewer could sample is being built.
Account deprovisioning
OperatingWhen someone leaves, their accounts on WebCastle-managed systems are disabled or removed and access to repositories, cloud consoles and production environments is withdrawn. A documented offboarding checklist that evidences each removal is being introduced.
- Removal is carried out by the technical lead responsible for each system.
- Credentials the departing person held that are not tied to an individual account are rotated.
- Confirmation that removal is complete is being formalized into a signed-off checklist.
Periodic access reviews
OperatingWebCastle is formalizing a documented access review cycle. Access to production systems and repositories is currently reviewed when team responsibilities change or a project closes, rather than on a fixed schedule.
- Reviews today are event-driven: joiners, movers, leavers and project completion.
- A scheduled review with a recorded outcome per system is the next step.
Password requirements
In practiceTeam members rely on the password strength and complexity controls enforced by each platform. A single documented WebCastle password standard applying across all systems is being drafted.
- A managed password manager for storing and sharing service credentials is being rolled out.
- Platform-level settings are being reviewed so that requirements are consistent rather than inherited.
Shared, generic and default accounts
OperatingNamed individual accounts are the standard, and default credentials on infrastructure components and third-party services are changed before a system carries live traffic. Both are being brought under a documented check so they are evidenced rather than assumed.
- A small number of legacy service accounts remain where a platform does not support individual logins; these are tracked and are being replaced or retired.
- Removal of vendor default accounts is being added to the documented pre-release check for new environments.
Centralized identity and single sign-on
Under EvaluationWebCastle is assessing a central identity provider so that provisioning, single sign-on and revocation can be handled from one place. No commitment to a specific approach has been made.
Privileged and administrative access
Held by a small group
Administrative access to cloud infrastructure and production environments is held by a limited number of senior technical staff. It is not a function of seniority elsewhere in the business, and it is not granted to project managers, designers or commercial staff.
Separate from day-to-day work
Administrative access is used for administrative tasks. Routine development and delivery work is carried out with standard project-level access, so that elevated permissions are not in constant use.
Root and owner accounts
Cloud provider root and organisation-owner accounts are protected with multi-factor authentication and are not used for routine operations. Day-to-day administration uses individual named accounts.
Activity records
Cloud provider native audit logging records administrative actions. WebCastle is improving how these records are retained and reviewed; today they are consulted in response to a specific question rather than monitored continuously.
Customer-granted access
Where a customer grants WebCastle access to systems the customer controls, WebCastle requests individually named accounts, follows the customer’s authentication requirements, and asks that access be revoked when the engagement ends.
Authentication requirements
- Second factor
- Required on cloud provider consoles, source control and other critical administrative services. Extension to all remaining business applications is in progress.
- Passwords
- Enforced by each platform’s own strength and complexity settings. A single documented WebCastle password standard is being drafted and is not yet approved.
- Credential storage
- A managed password manager is being rolled out for storing and sharing service credentials, replacing ad hoc sharing between team members.
- Credential sharing
- Named individual accounts are the rule. Remaining shared service accounts are tracked and are being replaced or retired.
- Remote access
- Team members work primarily from WebCastle offices and access systems over the internet using authenticated, encrypted connections. A documented remote access standard covering personal devices and untrusted networks is being developed.
- Customer systems
- WebCastle follows the authentication requirements of the customer whose systems are being accessed, including any customer-mandated VPN or bastion arrangement.
Who has access to what
An indicative view of access across the main system groups WebCastle operates.
| System group | Typical access holders | Authentication |
|---|---|---|
| Cloud provider consoles | A small number of senior technical staff acting as administrators | Individual accounts with multi-factor authentication |
| Source code repositories | Engineers assigned to the project | Individual accounts with multi-factor authentication |
| Production application environments | A limited number of technical personnel, approved per environment | Individual accounts issued through the cloud provider |
| Staging and development environments | The assigned project delivery team | Individual accounts |
| Business email and collaboration tools | All employees | Individual accounts with multi-factor authentication |
| Customer-provided systems | Only the team members the customer has approved | As specified by the customer |
Access is granted per project. Holding access to one customer engagement does not imply access to another.
What WebCastle is formalizing
The open work on access control, stated plainly so that customers can track it.
A documented access control standard
A single written standard covering provisioning, approval, least privilege, password requirements and revocation. Practices exist today; the approved document does not.
A scheduled access review cycle
Moving from event-driven review to a recurring review with a recorded outcome for each system, so that entitlement can be evidenced rather than described.
An offboarding checklist with evidence
A per-system checklist completed and retained for every departure, replacing informal confirmation by the responsible lead.
Central identity management
Evaluating a central identity provider so that joiners, movers and leavers can be handled once rather than per platform, and so that revocation is immediate and complete.