110 lines
5.8 KiB
Markdown
110 lines
5.8 KiB
Markdown
# Security model
|
|
|
|
## Public Azure deployment
|
|
|
|
The Azure topology supports certificate-authenticated P2S or direct enrollment.
|
|
P2S keeps AD services inside the VNet. Direct enrollment exposes the required
|
|
AD, DNS/DoH, WinRM, broker and RustDesk ports only to explicit public IPv4 CIDRs;
|
|
an empty allowlist exposes none of them. Azure NSG and Windows Firewall enforce
|
|
the same source list. RDP uses a separate allowlist. See
|
|
[azure-vpn-deployment.md](azure-vpn-deployment.md).
|
|
|
|
## Password handling
|
|
|
|
- The Credential Provider receives the password in Lithnet's secure password
|
|
control and keeps that `SecureString` for Windows serialization.
|
|
- A temporary managed string is unavoidable when creating the HTTPS JSON body.
|
|
The unmanaged conversion buffer is zeroed immediately with
|
|
`Marshal.ZeroFreeGlobalAllocUnicode`; managed references are released as soon
|
|
as each request completes.
|
|
- The broker uses the exact received value for both NTLM and AD `SetPassword`.
|
|
- There is no HMAC password, pepper, local password cache, Supabase password, or
|
|
other derived credential in this Windows path.
|
|
- Neither application logs request bodies or passwords. Deployment configuration
|
|
contains certificate thumbprints, not passwords or private keys.
|
|
|
|
## Transport
|
|
|
|
- HTTPS is mandatory on both links.
|
|
- Credential Provider to broker uses mutual TLS. The provider requires normal
|
|
Windows certificate validation and pins the configured server certificate.
|
|
- The broker requires a trusted client certificate and an explicit allow-listed
|
|
thumbprint.
|
|
- Client private keys are non-exportable and reside in `LocalMachine\My`.
|
|
- The NTLM validator rejects non-HTTPS redirects, URI user information, and hosts
|
|
outside its explicit redirect allow-list.
|
|
- Authentication and profile enrichment read only allow-listed HTTPS pages.
|
|
Profile bodies are capped at 512 KiB by default; portal cookies are
|
|
request-scoped and held only in memory.
|
|
|
|
## Profile minimization
|
|
|
|
- Administrative enrichment first verifies the employee number and reads
|
|
employee type/status, email, job title, and department from the incident
|
|
overview. Only after that match, it reads given names and paternal/maternal
|
|
surnames and the normalized `Male`/`Female` value from the personal page plus
|
|
street, exterior/interior number, neighborhood, locality, state, and postal
|
|
code from the location page. AD stores only the controlled `SGU-Gender` line,
|
|
not the original HTML field.
|
|
- Administrative birth date, RFC, CURP, blood type, marital status,
|
|
nationality, telephone, email lists, housing type, and emergency-contact
|
|
fields are ignored.
|
|
- Student enrichment reads only the matching student number, given names,
|
|
paternal/maternal surnames, email, career, street, neighborhood,
|
|
city/municipality, state, postal code, and normalized sex from known element
|
|
IDs.
|
|
- Student CURP, birth date, blood type, marital status, telephone, mobile,
|
|
guardian, medical, financial, and academic-history values are ignored.
|
|
- Professor enrichment keeps the menu display name as its base. From the payroll
|
|
consultation header it reads only a matching employee number, name, email,
|
|
employee type/status, job title, and the optional department field. It then
|
|
optionally reads the same structured-name and postal-address element IDs used
|
|
by staff pages. A missing professor route or element never makes authentication
|
|
fail.
|
|
- Payroll/receipt contents, incident details, calendars, photographs, manager
|
|
names, and manager positions are deliberately ignored.
|
|
- The employee or student number must match the authenticated `AD` or `AL` key
|
|
before role-specific metadata is synchronized. The two supplemental
|
|
administrative pages are never requested unless the incident page supplied
|
|
the matching employee number. Professor payroll metadata independently
|
|
requires the matching six-digit number, and every supplemental request uses
|
|
the same fresh, request-scoped NTLM session as its menu fallback.
|
|
- If SGU changes its HTML, authentication and exact-password synchronization
|
|
continue without enrichment; existing AD metadata is not erased.
|
|
- Slow profile pages cannot change an accepted credential into a rejection. The
|
|
lightweight NTLM root is authoritative; enrichment has its own independent total
|
|
timeout.
|
|
|
|
Lab self-signed certificates are appropriate only for the isolated VM network.
|
|
Use an enterprise CA with revocation checking in production.
|
|
|
|
## Recovery and availability
|
|
|
|
The provider distinguishes an authoritative rejection from unavailable
|
|
infrastructure:
|
|
|
|
- `400`/`401`: fail closed and show an error.
|
|
- timeout, TLS/connectivity error, `429`, or `5xx`: submit the unchanged credential
|
|
to Windows. Windows must still validate it against AD or the cached domain
|
|
verifier, so this does not grant access without the last synchronized password.
|
|
|
|
Redis is deliberately not used for password continuity. A second persistent
|
|
password verifier duplicates attackable credential material, while a reversible
|
|
encrypted password becomes a credential vault. AD and Windows cached domain
|
|
logon already implement the required last-known-password behavior. See
|
|
[`decisions/0001-no-password-cache.md`](decisions/0001-no-password-cache.md).
|
|
|
|
The installer never registers a Credential Provider filter and never disables
|
|
Microsoft's password, PIN, smart-card, or Windows Hello providers.
|
|
|
|
## Operational controls
|
|
|
|
- Limit the firewall rule to the Domain profile and required client networks.
|
|
- Delegate the broker service account only to `OU=Usuarios-SGU` and its managed child OUs.
|
|
- Keep broker/client certificates short lived and rotate their allow-list entries.
|
|
- Monitor service availability and AD provisioning events without enabling HTTP
|
|
body logging.
|
|
- Test uninstall and the built-in password provider before broad rollout.
|
|
- Do not test a new build first on a physical production endpoint; use a VM with
|
|
a recent checkpoint and a known local administrator recovery account.
|