This case involves Finserv, which is how people in the industry refer to financial services. There are two industries where security comes up as a priority in nearly every transaction. Can you guess them? Financial services is one because the transactions involved are both private and involve the exchange of value. The other is the healthcare industry, where a lot of the information is what they call PII or personally identifiable information. Let's see how security is handled in this financial services example. A lot of customers we see are in the enterprise space, so their needs are very similar. This example comes from a financial services company. We often see similar requirements among Finserv companies. So, a Finserv customer had this interesting business requirement. Encryption in transit and at rest for all developer operations. Follow Google Best Practices. All keys must be managed by the company. They wanted to own the keys. The real trick here is that the structure and solution had to be put into production at one time. It couldn't be built-in parts into production, it had to be all working when it went into production. That caused us to think about what parts were inherent and what parts we could automate. So, we ended up using a Jenkins Pipeline and Deployment Manager Templates for parts of this automation. We mapped that to technical requirements like this. Use Google authentication. No public IP access unless through a bastion host. No Operations team access to production environment, that means NoOps. Everything is automated. Minimize downloaded keys. Keys accounted for via business logic application. All the Google APIs are encrypted in transit and authenticated. So, that requirement was inherited and automatic. The production team needed operations access but without handing them the keys. So, what we did is implemented all operations in deployment pipelines using Jenkins and Deployment Manager. The business logic was implemented using Python in the Deployment Manager Templates. This is how we implemented that technical requirement. All Google APIs are encrypted in transit and authenticated. Production has Operations team access. All deployment pipelines via Jenkins and Deployment Manager business logic and Python templates and Deployment Manager. CloudSDK was not installed in local machines. Cloud Shell ensures that no keys are downloaded. Service Account Keys when needed for off-GCP clients are managed via deployment pipelines. There are two kinds of operations actions: on-GCP actions and off-GCP actions. For on-GCP actions, we didn't install CloudSDK on local machines. Instead, we set them up to use Cloud Shell, that ensured that no keys were downloaded. For off-GCP actions, the Service Account Keys were managed via the deployment pipelines. Anytime there was a need for off-GCP access, the clients are managed via the deployment pipeline. So, that means there's a full audit control and records of those keys, and who had access to them, and when and where they were used.
