Amastan · Pilot RC1 · Admin Guide
Amastan AI-SWG — Admin Guide
Deploy, identity, policy, verification, capacity planning, and what comes next.
Audience: Deployment engineers and security administrators
Related: User Guide · System Specifications
Updated: 2026-08-23
1. Scope
This admin guide covers installing the appliance, bringing up the HA stack, connecting identity, operating policies, verifying the deployment, and planning resources for larger user counts.
For click-by-click operator screens, use the User Guide PDF.
2. Prerequisites
- KVM/QEMU or compatible hypervisor for the pilot qcow2
- Adequate CPU / RAM / disk (see capacity table below and System Specifications)
- Management network access to Admin UI and (lab-only) sidecar
- Outbound access only as required for updates / threat intel (air-gap patterns supported later)
3. Obtain the appliance
- Request download entitlement from amastansolution.com (Contact / Downloads).
- Verify SHA-256 of
ai-swg-v1.0.1-pilot-rc1-sanitized.qcow2.
- Import into your hypervisor and attach networks per deploy docs.
Do not redistribute the image without authorization.
4. Deploy HA stack (summary)
On the appliance host (canonical lab path example: /home/swg/swg-project):
./scripts/appliance/deploy-lab-appliance-ha.sh
./scripts/appliance/run-lab-qa-manifest.sh
Confirm:
- Sidecar health (e.g.
:8010/health)
- Admin UI reachable (e.g.
:8080)
- Proxy path ready for clients
5. First admin login
- Open Admin UI.
- Complete onboarding wizard (policies, basics).
- Create / confirm admin users and RBAC.
- Change default credentials before any shared pilot.
6. Identity
- Configure LDAP/AD for user-aware policy and audit.
- Test directory bind and group mapping.
- Plan Azure AD / SAML / OIDC for later enterprise hardening.
7. Policy operations
- Maintain allowlist / blocklist / overrides.
- Use URL classifier test tools before broad enforce.
- Understand allow / block / RBI outcomes and appeal flows.
- Prefer staged enforce (monitor → enforce) for new categories.
8. Observability & SIEM
- Use embedded Grafana / Prometheus views for health.
- Export logs to your SIEM (syslog / object storage / webhooks as configured).
- Retain audit evidence for regulated pilots.
9. Backup & recovery
- Use built-in backup/restore procedures before major changes.
- Document fail-open vs fail-closed expectations for your risk policy.
10. Capacity planning — system tests by user scale
Use this table when planning hardware for a pilot or production-like site. Numbers are planning guidance from Pilot RC1 capacity tests and appliance sizing (TLS inspect on, typical office browsing mix, RBI used only for grey-zone / risky sites).
How to read “users”: named directory users. Concurrent active browsers are usually much lower (often ~10–20% at peak). Heavy RBI, full packet capture, or very chatty SaaS apps need more headroom.
| Named users |
Peak concurrent (est.) |
Nodes |
vCPU / node |
RAM / node |
Disk / node (SSD) |
Notes |
| Lab / demo (<100) |
< 30 |
1 |
8+ |
32 GB |
200+ GB |
QA + functional demo |
| 500 |
~50–100 |
1 (HA optional) |
12–16 |
48–64 GB |
500 GB |
Small office pilot |
| 2,000 |
~200–400 |
2 (HA) |
16 |
64 GB |
1 TB |
Standard pilot / mid-site target |
| 4,000 |
~400–800 |
2 (HA) |
24 |
96 GB |
1.5 TB |
Scale-up same HA pair; watch classify latency |
| 10,000 |
~1,000–2,000 |
2–3 |
32 |
128 GB |
2 TB |
Add node or split roles; SIEM export sizing matters |
| 20,000 |
~2,000–4,000 |
3–4 |
32–48 |
128–192 GB |
4 TB |
Multi-node / fleet design; validate with load test before go-live |
What we measure in system tests
- Proxy path health under concurrent sessions (allow / block decisions)
- Classify latency and error rate on the AI sidecar
- HA failover (one node down — traffic still decided)
- Log / dashboard growth (disk retention for audits)
- Optional RBI capacity (isolation is heavier than allow/block)
Before a large rollout, run a scoped load test on your traffic mix. We help size this during the 4–6 week pilot.
11. Verification checklist
- [ ] HA deploy completed
- [ ] QA manifest acceptable for pilot scope
- [ ] Admin MFA / password policy set
- [ ] Directory integration tested
- [ ] Sample allow / block / RBI proven
- [ ] SIEM or log export verified
- [ ] Client proxy path documented for pilot users
- [ ] Capacity profile chosen (2k / 4k / 20k …) and hardware reserved
12. Features coming in the future
Pilot RC1 focuses on deep self-hosted SWG. Planned next (dates can move):
Harder to skip the filterClose modern browser / DNS bypass holes; official skip-inspect only for sites like banking.
Stronger IdPAzure AD / SAML / OIDC hardening on top of LDAP/AD.
Safer ChatGPT / CopilotBlock pasting source code or customer files into AI prompts.
Finer cloud-app controlNot only allow Salesforce — allow view, block download.
Private work apps (ZTNA)Reach one internal app without a full VPN.
Multi-site fleetSame rules across offices; one health picture.
Malware / attacker sitesStronger known-bad file and C2 blocking; sandbox unknowns.
Automatic follow-upAfter an incident: block site, open ticket, notify SOC, or disable account.
Richer SIEM + audit packsExports auditors can download as a file, not only screenshots.
Sector packsReady rule sets for banks, government, education, and partners.
Licensed options today/soon: DLP (stop secret uploads), Shadow IT / unofficial cloud apps — when enabled on your contract.
13. Support
Pilot questions: use the Contact form on the official website or email the project contact in your pilot pack.
© Amastan — Admin Guide for Pilot RC1. Print → Save as PDF if needed.