Hello. Welcome to 'This is My Architecture'.
I'm Anshul, and I'm here today with Badri from Singapore Exchange.
Welcome, Badri. Hey Anshul, nice to meet you here.
Badri, can you tell us a bit about SGX
and especially the investor portal, which we're going to talk more about today.
Yeah, sure. So Singapore Exchange is Asia's leading multi-asset exchange,
operating in equities, derivatives, and the fixed-income markets.
So the investor's portal,
it's a single point of contact for our retail investors
to open their trading account, what we call central counterparty,
and to manage their investment portfolio that they trade with multiple brokers,
and to access the company prices and the information itself.
Great, so maybe can you walk us through what happens
when, as an investor, I log in or access the portal?
Yeah, so the investors portal itself, is a single-page application.
Presented fully with a combination of AWS edge services.
So here the frontend artifacts are processed in an S3.
And so through AWS content delivery network, it's CloudFront.
Along with the combination of edge services with WAF as our edge Firewall,
and Lambda@Edge is our edge compute.
And finally to present the artifact back to the user.
So you'll notice that, as a serverless platform,
we take that foundation of Lambda@Edge
for all of our compute functionalities, to execute this compute,
deciding on the frontend routing,
when it comes to our frontend, single-page application itself.
So when the frontend artifacts are loaded into the user browser,
you can decide to log into the portal
and you can choose your SingPass, to log into the portal.
SingPass is basically a one-account management
to access Singapore government e-services.
So when the user invokes a session API call, the backend API call,
The API itself is passed through from the AWS API Gateway.
The user gets redirected back to the SingPass portal.
Where the user gets authenticated,
and they're redirected back through our backend.
And the backend services,
what we call the EC2 instances that creates the user session,
responds back with the session information.
So for the subsequent API calls,
the user can carry their session information along with their http payload.
So from the API Gateway,
we would not directly invoke our… the underlying micro-services.
Perhaps Lambda authorizes as our step zero.
This…
interacts with the ElastiCache
and to decide whether to allow that user's API action to execute or not.
So that's pretty much it about this investor's portal application,
and what goes behind the screen.
When you log into the portal itself.
Great, can you also touch base
on some of the security considerations
that went into this to safeguard investors' data,
as well as well as comply with regulatory and compliance requirements?
Yeah, sure.
So, as an exchange,
we take the security considerations very seriously,
and we are highly regulated as well.
And, you know, given the nature of data as well,
what's involved in that application,
we made a conscious decision to encrypt everything,
and that includes the data in transit and data at rest.
And also the mutual accession to authenticate the system,
you know, that includes authenticating the system
in the AWS services, backend AWS services,
and from AWS back to our data center as well.
So for our frontend application itself,
you know, for the data at rest, the KMS, our server key management service,
along with the default encryption that we have in S3
to encrypt everything at rest.
And also I can emphasize on the Lambda@Edge,
so the Lambda@Edge as our only compute functionalities.
We have a lot of other considerations to introduce as security headers.
So that is made possible through the Lambda@Edge.
And both out of API following through and subsequent,
you know, the data in transit with the SSL calls itself.
And from an API perspective,
so we rely on the API Gateway client certificate.
Client cert for the mutual TLS authentication.
So this carries the identity for any subsequent calls
back to the micro-services,
and for the API calls back to the data center,
the client certificate carries the cached http payload
that can show certificate identity to validate the mutual accession.
And other than that from the data perspective
ElastiCache with the KMS on for the data at rest,
for the ElastiCache data considerations,
And the typical… you know the data in transit
with the SSL calls itself.
So that's pretty much it for the security considerations
that went into the portal. That's great.
Can you also touch base on some of the benefits
that you achieve by moving this to cloud?
So, I can say from the technical benefits
of the combination of edge services that we rely on
in this platform to do most of our heavy lifting.
So the benefits include scaling the platform,
and as well as the security.
The high security implementation part we can…
What we can do in AWS
with the combination of AWS edge services itself.
So I can also recollect, at the time of the launch,
when the average daily usage volume got doubled.
But irrespective of that surge,
We could scale this platform seamlessly to support that demand,
making it a successful launch itself.
That's great. Thank you for sharing this Badri.
As an investor, the next time I log into this portal,
I'll definitely be at ease knowing the security nuances
that went into this. Thank you for sharing.
Thank you, Ansul. So pleasant being here.
Hope you all enjoyed watching this at home.
Thank you for joining 'This is My Architecture.'