Transcript
This transcript was autogenerated. To make changes, submit a PR.
You. Last year,
the average cost of a data breach was a staggering
$4.35 million. As exorbitant
as this number is, it represents a 2.6% increase
from the previous year. These findings are from IBM's
cost of data breach report. The serve as a reminder
on the importance of secure architecture welcome to
Conf 42 platform Engineering conference and
thank you for attending this session. I'm Arthur Siddiki,
senior principal software engineer at Silicon Valley bank,
division of First Citizens bank.
This talk will be split over three sections,
starting off with zero Trust and why it requires
our attention. The next topic will
be network segmentation and how AWS transit Gateway is
a key enabler. The third and the last session
will do a walkthrough on the cloud design coupled with
traffic inspection. The term Zero trust
dates all the way back to 1994.
Yep, it is that old. 1994 Stephen
Paul Marsh, a computer science professor, was studying trust as
part of his doctoral thesis. As part of his research,
he was quantifying trust as a finite entity,
that cloud be described mathematically. It is in this
thesis that he's first credited with using
the term zero trust. Fast forward to 2010.
The term zero trust model was coined by John Kinderbag.
He wrote a paper for Forrester research titled
Build Security into your network's dna.
The Zero Trust Network architecture it is safe to
say that the emergence of zero trust model has been gradual.
While there are other data points indicating the industry
acceptance, in my view the impactful endorsement
came in August 2020. That was a time when National
Institute of Standards and Technology, commonly known as NIST,
published a document titled Zero Trust Architecture.
Zero Trust at its core rejects the trust
but verify approach and proposes the motto never
trust, always verify principle include
explicit verification, least privileged access and
minimizing blast radius. The focus of this presentation
will be on segmentation known
by multiple names, isolation partition or segmentation.
This network architecture approach divides the network into
smaller networks. This is especially an effective
approach in organizations that traditionally have
had flat networks. It reduces
the attack plane because lateral movement in the network
is being restricted in AWS cloud,
transit gateway can be used to create sophisticated network
architectures. Security posture can be
further elevated by introducing traffic inspection appliances.
Transit Gateway was announced during reinvent of 2018
as a software defined cloud router. It employs a
hub and spoke model. A popular
deployment model is to provision transit gateway in an
account designated as a foundational network account.
Transit gateway can then be shared via resource access manager
to all other spoke accounts.
To better understand how transit gateway works,
let's understand some of the fundamentals transit
gateway attachment is what allows resources example a VPC
or direct connect gateway to connect to transit
gateway, therefore, in every spoke account,
attachment needs to be provisioned. An attachment
manifests itself as an elastic network interface, or Eni,
while a single Eni can be created for
resilience. Multiple subnets should be specified
which will correspond to enis across multiple availability
zones. It should be mentioned there are other types of
transit gateway attachments, VPN pairing,
connection and connect. However,
this session will concentrate only on the VPC attachment
type. When a transit gateway is created, it also
provisions a default transit gateway route table.
As required, this default table can be
purged and new ones created to isolate the attachments.
All routing decisions done by transit gateway rely
on transit gateway route tables. Coupling of
a transit gateway attachment to a transit gateway route table
is what's called an association. A given attachment
can only be associated with one transit gateway
route table. Propagation is what allows transit gateway
to learn routes dynamically from its attachments.
For example, in this picture, since propagation is enabled
on the next slide, there's an automatic entry under
routes. Aside from propagated
routes, static routes can also be created.
In terms of route evaluation order, static routes have
higher precedents than propagated routes.
Additionally, the more specific a route, the higher
is its priority. Having done a quick walkthrough on the fundamentals,
how do we distill these learnings into the design while keeping in view
of these considerations an
AWS ecosystem that uses AWS organizations
to implement multi account strategy.
One of the best practices is to have separate accounts for each
environment to limit the blast radius. Therefore,
if an application has four environments,
dev, QA, UAT, and Prod,
there will be four AWS accounts. Cross account routing will
be managed by a combination of VPC and transit gateway route
tables. In regard to transit gateway route tables,
there will be two tables configured,
spoke and inspection. The last consideration
is identifying the traffic flow that is of interest to us
on prem is the traffic from AWS ecosystem
to on prem data centers, and vice versa.
Inline is espresso traffic traversing
from one AWS account to another.
Egress is outbound connectivity to the Internet.
For example, an application workload hosted an AWS
account that needs access to the Internet. Traffic inspection
relies on a centralized deployment model. As shown in the diagram,
there are three sets of firewalls deployed in separate vpcs.
These firewall appliances reside in the same foundational
account where transit gateway is provisioned.
The strict control that is being enforced is that
all traffic crossing a VPC boundary must be inspected.
In fact, even in a multi VPC account,
traffic from one VPC to another VPC in the same account
must still go through a firewall. I realized there's a
conspicuous absence of ingress, which is traffic
coming into an AWS account from the Internet. I chose
to descope it as it requires additional controls that can
end up being a topic on its own. Similarly,
implementation details for on prem connectivity have
also not been discussed.
Again, the depth of topic to include direct connect
VPN or SD WAN overlay with transit gateway
Connect are topic on its own.
The design being presented here references two application accounts
with highly creative names, app one and app two.
App one has a VPC cider of ten 124
00:23 while app two
has a VPC cider of ten 128 00:23
the second picture depicts corresponding ciders
for vpcs in which the firewalls have been provisioned.
Default transit Gateway route table has been pursed and two
new ones created to isolate the attachments.
Spoke and inspection on
the spoke route table is where the spoke
vpcs are connected. Therefore,
under associations are listed the transit gateway
attachments of app one and app two within
this spoke route table under routes static
routes have been configured. The design assumes that
ten
is a super block for AWS ecosystem.
Therefore, if target IP is from the 16
super block, the third route is in play as it
is the most specific route. In this case,
the next hop is the attachment for inline firewall UPC.
If the target IP is not from 16 super block but
still from the 100 zero eight
range, it is treated as on prem traffic. In this
case, the second route is in play and next hop
is the attachment for on prem firewall VPC.
Finally, if cardio IP is not part of the ten eight
range, then the least specific route comes into play.
This is treated as egress traffic and next
hop becomes the attachment for egress firewall VPC as per
the first route, moving on to the second transit
gateway route. Table name inspection this is where the firewall vpcs
are connected. Therefore, under associations
are listed the attachments for egress inline and on prem
firewall vpcs. After application traffic
has been inspected, final hop of the network path has
to be determined. Let's say app one
was talking to app two, which means that the destination
IP will be within ten 128
00:23 range. That is because this is the VBG
cider of app two. Therefore, the last route
is in play and corresponds to the transit gateway attachment of app
two for completeness. If app
two was talking to app one. Then the destination IP
will be within ten 124 00:23
range, because that is the VPC cider of App one.
In this case, the second last route is in play and
corresponds to the transit gateway attachment of app one
down the line. As new application accounts are onboarded,
specific routes will be appended here for app two, three, four,
et cetera. Let's briefly talk about VPC routes
to understand how routing decisions happen at
the origination point. This diagram shows
VPC route table for app one,
the first route has been inserted, which states that for any non
local route, destination is specified as a transit
gateway, which then gets full control of transit routing
circling back the goal of this presentation has been
to look at network architecture approach under
the purview of zero trust. What if we wanted
to take this a step further? What if a Dev account
shouldn't talk to UAT? What if dev environment
shouldn't even have a network path to UAT? What if
QA cannot talk to production? What if the
control state that environments cannot mix? Dev environments
are only allowed to have a network path to other dev environments,
QA environments are only allowed to have a path to other QA environments,
and so forth to cater to this additional requirement.
This is how the design can be enhanced. Instead of a single
spoke route table, design will extend to
four transit gateway route tables,
Devspoke QA spoke, UAT spoke,
and prod spoke. With this approach,
transit gateway attachments of Dev vpcs will be attached
to Devspoke transit gateway attachments of QA
will be attached to QA spoke table, and so forth.
By raising the number of transit gateway route tables, higher granularity
of routing control is permitted. In addition to existing
routes that force traffic to firewalls,
a fourth route can be inserted of type
black hole. Therefore, on a despoke route table
if the destination IP is from a sided range
of QA, UAT or production vpcs,
it will be directed to a black hole. This will
ensure there's no network path from a dev account to
any other non dev account.
Similarly, black hole routes can be inserted on the QA spoke, UAT spoke
and prod spoke route tables. I will leave with one
final food for thought. What if there is a new
incremental requirement to have separate inspection
appliances production firewalls being separate from
nonproduction firewall appliances? The design remains
extensible for this requirement.
A new set of firewalls egress inline and on prem
will have to be deployed in their own vpcs and
a second inspection transit gateway route table will need to
be introduced.
There is a rising cost of data breach that we started off the discussion
with. Even more impactful is the hit to
the brand reputation and a loss of customer confidence when
data breach occurs. Importance of security architecture
cannot be overstated. Zero Trust provides
an excellent reference architecture that allows organizations
to incrementally improve their enterprise architectures.
Thank you all.