We believe that having truly empowered employees increases productivity, lowers costs, increases quality and as a result, improves customer satisfaction! So as a bank operating in a heavily regulated industry, the million-dollar question is: how do you set up and maintain an environment where you adhere to the regulations while at the same time ensuring that you have empowered employees?
As authors of this blog post, we don't claim that we have the golden eternal answer to that. However, since we were given the possibility to help SEB implement a brand-new platform with the use of public cloud and Google Cloud Platform (GCP), we'd be unwise if we didn't take the opportunity to try to improve! So, here are some key areas we have been working with:
- Empowering through knowledge sharing
- Everything as Code
- Built-in security
Empowering through knowledge sharing
Knowledge is power and we see knowledge as one of the keys to make developers feel more empowered. The following are a few examples of how we work with increasing and sharing competence across teams:
- Cloud Tech Guild: Even for us who actively work with Cloud, there's new stuff coming up all the time so here where we share information on what is going on in GCP and how teams are solving challenges. This helps to tear down walls between teams and help them to avoid re-inventing the wheel by the sharing of information
- Security Champions: Security awareness is key and doesn't have to be a chore, so why can't security be fun and cool? In order to keep the security awareness and coolness high, and maintaining a critical mass of knowledge, every delivery team using our cloud platform has to appoint a Security Champion which is a person that drives the security agenda in the team. Also, the Security Champions meet monthly with the core team to discuss selected topics and are the natural lead for security questions.
- Freedom: Freedom to create and innovate in their own isolated Google projects by leveraging Google's wealth of services and computing power.
Everything as Code
We want the application delivery teams to have full control over their release cycles, follow best practices as well as regulations controlling the financial markets. To do this the releases must be deployed in a reproducible, secure and transparent way which can be audited. Therefore, methods to deploy must be fully automated and access rights to the production must be restricted to an absolute minimum.
For the Cloud Platform, we decided to go with Hashicorp Terraform for setting up, changing, and versioning the virtual infrastructure of Google Cloud safely and efficiently. Terraform uses declarative definitions, meaning that you declare what you want in an intuitive way. Here is one simple example of how to define a firewall opening:
resource "google_compute_firewall" "my-fw" {
name = "my-app-firewall"
network = "my-nw"
allow {
protocol = "tcp"
ports = ["443"]
}
}
So, no scripting and no room for human error by longer clicking in a GUI, instead you rely on Terraform to do the heavy lifting for you! But how does Terraform know how to do that? The answer is that Terraform has a number of maintained "providers" and the Terraform Registry is where you can find documentation about available providers.
Automation does not reduce all risks though so there's still room for making mistakes and or even committing fraud. To prevent that, the Four Eyes Principle comes in to play where any change that involves a risk must be reviewed and double checked by a second individual before being approved to deploy to production!
Built-in security
So we want independent and efficient teams who feel happy, think about security and are kept safe. As a way to make the teams feel safe we provide a number of guard-rails that are there to stop teams from making unwanted mistakes, while not hindering the teams. Here are a few examples:
We have a hands-off policy in acceptance and production project so teams are given some read access to their acceptance and production project but all changes are applied through the Terraform pipeline.
Main branches reflect production and are protected using pull-requests, reviewed by another team member.
We use Organization Policies in GCP as a way to restrict certain configurations of resources which constitute known security-related risks. One example is that we restrict data storage outside EU and another is that we by default block unauthenticated access to end-points.
GCP also offers a large number of services, like Compute Engine, Cloud Data Store, BigQuery and some have their own terms of service. So to secure that all GCP services that we use are compliant with EU and financial law we review each service separately before making it available to the teams.
Keep safe and have fun!
