Hello and welcome to 'This is My Architecture'.
I am pleased to be joined today by Marco Rinalducci.
- Hello Marco! - Hello Jerome!
Well, Marco, can you tell us a little bit about Pictet and what you do there?
Of course! Pictet is a bank established
over 200 years ago in Geneva
and is active all over the world.
We have a long-term vision with a strong client focus
through our four business lines which are:
Asset Management, Wealth Management,
Asset Services, and Alternative Advisory.
Very good.
So, I imagine that as a financial company, you have quite a few security needs
and I see on the architecture diagram
that you have both external and internal accounts.
Can you explain that to us?
Yes, we actually have a multi-account approach.
So, we have multiple AWS accounts per user
and we have defined a terminology of external and internal accounts.
So, external accounts actually are using a two-way access to the Internet
through an Internet Gateway
and internal accounts are actually
using a two-way connection through a Transit Gateway
and then through a VPN, to our Corporate Datacenter
which spans the globe.
Great.
However, is there a communication between the external and internal accounts?
There is actually.
We use AWS managed services
such as S3, SQS, and even SNS
to actually enable a one-way flow of data,
and gather data from the Internet.
So, we go through these services
to have flow control and then to avoid potential data exfiltration.
All right. Great.
OK. So, I think we've pretty much understood the network topology.
I see that you also have quite a few security services.
Can you explain briefly how do you use these services?
Yes, we decided to use the AWS native security services
such as GuardDuty, Config and Security Hub.
We basically consolidated these security services in the Security Hub
in order to have an overview of the anomalies.
These anomalies also trigger notifications directly to the people involved.
Great.
I also see on the left-hand side, you have Organizations, Service Control Policies,
I assume it's to manage some governance on all these accounts.
Exactly. So we actually use...
We mostly use AWS Organizations and SCPs
to restrict access to certain regions,
certain services, or even to block certain services
in some external or internal accounts, but mostly internal accounts.
We also use AWS Organizations extensively
to deploy services such as Config.
Especially with the Config rules,
we can centralize these rules in one place
and deploy them in all accounts.
For example, we implemented a rule
that basically prohibits serverless Lambda functions from being off VPC
in order to control the flow and then the exfiltration of data.
OK.
I see that there's some pretty strong governance,
which is pretty logical for a financial company.
So, when a team asks you for accounts or AWS services,
how do you implement that?
Well, we've set up
a Shared Responsibility Model with our customers,
- which are the people who use the platform that we've set up, -
and the team I work with.
So, this allows us to...
Actually, we deploy everything with Infrastructure as Code
via a CI/CD deployment chain
and our users can also use the same CI/CD deployment chain
to develop their workload on our platform.
That allows us to give them great flexibility,
while still having a certain amount of freedom on the matter.
In addition, for some critical services or elements
such as certain parts of the network or IAM,
we have implemented a validation system through pull requests.
Once again, this allows them to request changes
with prior approval from the team.
OK. So, everything is automated and secure
which will allow you to scale up to the cloud.
Exactly.
All right. So what are the next challenges or the next milestones?
Well, the current challenges are mainly related to the training of our colleagues
or the users of the platform.
Therefore, both on the platform and on AWS,
since we also need to acquire knowledge at that level.
Regarding the next steps, or the big work in progress:
we're probably going to implement and replace the VPN
with a Direct Connect
and also allow internal accounts
to have Internet access through a Transit VPC
but only on URLs that are pre-allow-listed
or pre-authorized by the team.
All right.
Thank you Marco for sharing this architecture with us.
Thank you very much, Jerome.
Thank you for watching 'This is My Architecture'.