Currently z/OS Validated Boot only operates within the scope of a single z/OS LPAR (or z/VM guest in limited fashion) — what I'll refer to as a "Stage 0" configuration (in Enable mode). Thus it's currently possible for a z/OS Sysplex to consist of validated and non-validated z/OS images, inadvertently or intentionally and with no "speed bumps" to a mixed validation Sysplex. Participating z/OS images in a Sysplex often have high privileges, such as the ability to access data via Db2 data sharing as one example.
This idea is to recommend extension of z/OS Validated Boot principles to Sysplex-wide scope. I think three complementary approaches (stages) make sense in this context. These stages could potentially be on separate but complementary development and delivery tracks. First, it would be possible to configure a single- or multi-machine z/OS Sysplex such that only Validated Boot(ed) instances can join the Sysplex. This would be the "Stage 1" Validated Sysplex configuration. *Any* Validated Boot(ed) z/OS, even trivially validated, could join a Stage 1 Validated Sysplex, so this stage would offer only basic protection to a Sysplex. In a "Stage 2" Validated Sysplex configuration, participating z/OS instances would need to be properly cryptographically signed to participate in that Sysplex. (And most likely dual signed and validated, both classically and quantum safely.) Otherwise, they're barred from joining the Sysplex. They would all need valid signing for the particular Sysplex they're joining. It would also be possible in a "Stage 2" Validated Sysplex configuration to cryptographically sign z/OS images such that they're eligible to participate in multiple Sysplexes that have different signatures. (Sequential participation, of course.) Multi-Sysplex signed images would likely be useful for test Sysplexes and Cyber Vault-related installations, as examples. Finally, a "Stage 3" Validated Sysplex (and also applicable to a single Validated Boot z/OS instance) would be digitally signed such that it can only run on particular specific machines based on their public keys. All 3 stages would be optional, although warning messages and logs/SMF records would be generated for configurations that do not incorporate the full Stage 3 protections.
Some careful thought (and probably design) would need to be given to whether signatures should expire in time (optionally yes, I think) and should be subject to revocation (definitely). The need for Sysplex-wide security should be balanced with operational and disaster recovery scenarios. Defaults should be consistent with best security practices and operational necessities. For example, should a participating, running z/OS image be ceremoniously ejected from a Sysplex when some expiration date is reached? Under what circumstances, and with what warnings/delays? Or should that image simply be unable to rejoin if/when restarted? Would it make sense to offer randomized expiration times as a Sysplex is formed/reformed? Could any z/OS image start up, even if expired? (Except it simply wouldn't be allowed to join in a Sysplex.) But the basic idea here is that z/OS is operationally a multi-member constituency in reality (and in how it processes data and runs applications that access data), so z/OS Validated Boot and related concepts should extend to each whole constituency.
Please recategorize this idea if it does not belong under BCP_General.
