Tom Longfellow wrote: >1. Do you really log in to your peripherals that much for it to be an >issue? Is this a case of 'We have LDAP, everything must use it'? >2. What is wrong with a small self contained local authentication >method? No one will stumble across YOU while they are hacking >your corporate LDAP or AD.
I'm curious if anyone has other answers, but I think there are reasonable answers to both of these questions. Employees come and go, and their roles change even more often. Thus many organizations understandably want to manage identities and roles centrally. Sometimes they're required to do so on pain of civil and/or criminal penalties if they don't. It's much easier to manage authorizations centrally when they have fewer siloed authentication/authorization engines to worry about. It also tends to be easier to secure one security engine (or fewer security engines) instead of scores or hundreds. Moreover, a centralized approach is easier for operators and administrators, too. It's precisely when you don't log into something too often that you forget *that* password precisely when you need it most. >3. Security Begins At Home. What happens when your disk system >needs a quick adjustment or command to Save your z/OS (or even >LDAP or Linux) IPL and Recovery? Not staying local can lead you to >the equivalent of 'locking the keys to your piggy bank INSIDE your piggy >bank' -- ALSO don't save the only copy of the master FDE encryption >key inside the disks protected by FDE encryption (piggy bank model 2) The typical implementation is that there's a "break glass" alternative that neatly addresses these concerns. (RACF is analogous.) However, the device in question is the IBM TS7700 virtual tape library. In this case it happens to be a z/OS-dedicated device but not a z/OS startup device. It seems like you can safely assume that (at least one instance of) the IBM Directory Server for z/OS (LDAP) will be up, running, and reachable at all times this device is relevant. The better analogy is that the TS7700 is the bank, and you can safely assume there's always at least some money around (z/OS). Otherwise the bank has no relevance. I would feel more nervous along the lines you suggest about configuring the TS7700 to rely on an "external" LDAP server. In such cases you should figure out a viable (but still secure) "break glass" alternative if the LDAP server is down or unreachable. Note that LDAP servers can synchronize with each other, and if the synchronization is interrupted it's not an immediate emergency. (Also see below about GKLM.) >If my key system is in a small, self contained, and properly backed up system, >I feel better than if I have to go to other organizations and other platforms >and other networks to support the basic functions of the device. "It depends." Security is sometimes hard, and there are reasonable arguments for having a dedicated, centralized security operations team handling various housekeeping functions. For example, if you forget to renew a certificate then your organization can have a really bad day. Maybe you "forgot" because you're stuck in a hospital ICU? A competent, centralized security operations team would be less likely to forget. I think here the decision was made to centralize certain security functions to some degree (TS7700 to z/OS LDAP) but not completely (to some other LDAP server). Although these LDAP servers can replicate with each other, so if desired there can be logical centralization without excessive physical centralization. That's an attempt to balance competing interests, and I think it's a good one actually. I've recommended exactly this sort of approach in other situations (replicated LDAP servers with z/OS hosting one logical instance). >I was recently forced to move my SKLM key servers from hardware >under my control to Virtual Machines that they Promise will be >available. I did bring up the point that one screwup that is now >out of my control will DESTROY the ability to open the DS8K data >arrays. I was so happy to find that SKLM functionality became an >internal feature on USB sticks, BUT the hardware they purchased >still does it the old way. I believe we suggest that you deploy IBM Security Guardium Key Lifecycle Manager (GKLM) in at least a couple "places." For example, you can run GKLM in the z/OS Container Extensions *and* on VMware. Or you could run GKLM in the z/OS Container Extensions "on premises" (on one or more of your machines) and also in a public commercial cloud such as IBM Cloud Hyper Protect. We do offer a USB-based alternative, true, but then you have some other management and security considerations. That's why there are multiple options. Your IBM DS8000 series storage units already have some external dependencies, and you presumably take reasonable steps to assure that those external dependencies are well implemented and managed so that they don't jeopardize the availability and performance of your storage units. External dependencies include cables, electrical power, and (often) SAN switches. Is your key manager any different conceptually? No, not actually. So just have "a couple," as you do with redundant cables, power, and switches. And if you're nervous about putting all GKLM instances in one type of deployment environment — I can understand that — then just spread GKLM across two environments. zCX is an excellent one. — — — — — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
