Hi, I support a comparatively small project of around twenty OLTP instances on AWS. My customer expects both full auditing and least necessary privileges in all environments -- which hasn't been a problem for code development and artifact promotion. My team lead explains Zero Trust, however, that even with full-monty auditing of everything, all DBA activity outside of development is limited to pre-written scripts. No SQLcli, no TOAD, no SQL*Developer, no Putty. And because we're homed on AWS, SYS or SYSDBA commands are available only through the RDSADMIN account.
I'm asking to learn from you experts whether this description is typical of a Zero Trust shop; and if not, point me toward sources that might help improve my options. TIA.
Zero trust models do not explicitly state that adhoc access is prohibited - more that access is always controlled, secure and monitored.
Some of our own info here https://www.oracle.com/security/what-is-zero-trust/ https://www.oracle.com/a/ocom/docs/whitepaper-zero-trust-security-oci.pdf
both of which come from the initial 8 basic principles from NCSC
1 know your architecture including users, devices, and services
2 know your user, service and device identities
3 know the health of your users, devices and services
4 use policies to authorise requests
5 authenticate everywhere
6 focus your monitoring on devices and services
7 don’t trust any network, including your own
8 choose services designed for zero trust
However, an organisation of course can choose to adopt/implement those principles however they use. Inside Oracle, we're more likely to take advantage of facilities like DataVault, which allows administrative access whilst still not being able to see the data. (Critical for our cloud management of customer data).
In my experience, pre-written scripts can often be just a facade of security because minimal validity checking is done on the *content* of the script. A command that erases your database works equally well adhoc or in a script :-)
But if script access is all that is allowed, make sure you've got your SLAs covered in that responsiveness to issues is likely to be slower and that resolution to critical issues (database recovery etc) might be more difficult. If the client is happy to sign off on those compromises, then at least you know where you stand.