aporeto - identity powered security · apis accessible via http/grpc making ips irrelevant....
TRANSCRIPT
Identity Powered Security
www.aporeto.comCloud-Native Security
www.aporeto.com
Executive SummaryAs the move towards a digital world continues Enterprises have a greater
responsibility to protect access to their data from bad actors. Security breaches are
no longer an if condition but a when condition. When there is a breach the best
option is to reduce risk by containing the breach blast radius.
At Aporeto we have taken a unique approach to mitigate lateral attacks while
allowing our customers to consume cloud, build cloud-native applications and
improve application velocity. De Facto workload/application segmentation
technologies in the industry are IP infrastructure centric. An IP centric approach to
security introduces an overwhelming amount of complexity and a failure to establish
a strong security posture. Our assertion is security must be abstracted from IP
infrastructure to address application segmentation requirements and improving
your application risk posture.
All network segmentation solutions that exist today tie back to IP infrastructure in some way. This goes for micro-segmentation solutions or cloud security groups offered by popular cloud providers. The above illustration demonstrates the problem with IP whitelisting. If you are to consider a set of six workloads that need to be whitelisted you will need to define and/or manage (6*(6–1))/2 number of rules; it boils down to an (N*(N-1))/2 problem where N is the number of endpoints. As the number of endpoints increases the number of policies increases and the increase is non-linear. Some vendors hide the complexity of defining these IP rules with abstractions but hiding complexity does not address scale limitations. A change in any one of the endpoints requires an update to all other endpoints. As the number of endpoints increases the operational burden of managing these rules increases. Whitelisting is the right approach but the complexity has to move towards an order of N problem – more on that approach later.
How Network segmentation does not reduce your risk posture Shrinking a large IP perimeter with IP whitelisting
increases complexity & reduces scaleNetwork segmentation technologies today can shrink a large IP perimeter behind a firewall to a smaller perimeter utilizing IP whitelisting. Unfortunately an IP based perimeter still exists and is ineffective in reducing the threat surface for your high value assets. Let’s address some of the limitations of this approach to segmenting your applications.
www.aporeto.com
# of endpoints 4 6 8
6 15 28# of whitelist policies
Hybrid and multi-cloud introduce multiple IP domains. It is well understood IP networks are not one flat layer today. Network Address Translation (NAT), Proxies and Load Balancers are common and all of these technologies mask IP addresses. IP whitelisting cannot span multiple IP domains. The only way to get around this issue is to enforce course IP whitelists that allow all traffic from a given IP domain.
This Illustrates the consequences of this approach. A single compromised host in within the on-premise data center now has the ability to laterally move to the cloud. As a bad actor, Ii can also spoof my address to pretend Ii am originating from a specific IP range even though Ii am not.
IP whitelisting increases threat surface for hybrid/multi-cloud
www.aporeto.com
!
API
Cloud IP Perimeter
Microservices
FW
VPNs,Tunneling/SDN
DC IP Perimeter
App App
Containers
API
Cloud nativetechnologiesbreak IPwhitelisting
Agile development practices with microservices and the adoption of cloud-native technologies such as containers further strain security policy enforcement based on IP. Microservices are exposed through APIs accessible via HTTP/gRPC making IPs irrelevant.
Containerized workloads can be replicated, rescheduled and rehosted. The dynamic nature of container workloads implies IP addresses are no longer persistent identities to be used for security policies.
www.aporeto.com
Visibility is critical to understanding sanctioned and unsanctioned communications for your applications. All network & security visibility solutions today rely on IP as the application identifier. Applications spanning heterogeneous environments always span multiple IP domains which means one would have to stitch IP flow data across these disparate environments to get an end-to-end picture; almost an impossible undertaking.
Application visibility in heterogeneous environments
www.aporeto.com
Cloud Region 2
CloudFlowLogs
Cloud Region 1
CloudFlowLogs
App
On-prem flow logs
On-prem DC
App
Identity-powered application segmentation
www.aporeto.com
The concept of identity is well understood for users logging into popular web applications such as email. Source IP of a user can come from anywhere on the internet making IP whitelisting users impossible and extremely insecure since IPs can be spoofed. Strong user identity can now be provided by popular identity providers such as Ping, Okta, Google Auth etc.
Modern application workloads depict the same characteristics as users; workloads can now exist on any cloud and be rescheduled or re-hosted much like ephemeral users. Application workloads need a persistent identity that can be used for security policy enforcement.
Authenticateand Authorizeusing identity
User
IdentityProvider
App
Assign every workload cryptographic identity.
Distribute policies to end-points but manage policies centrally.
Segment every app and API by authenticating & authorizing all requests.
At Aporeto we are bringing the concept of user identity to applications. Our approach is to assign every workload with a cryptographically signed identity that is dynamically derived by introspecting multiple sources:
www.aporeto.com
Operating system (OS): Derive which user (UID, GUID) launched the application
Cloud Instance metadata: Example is AWS EC2 instance identity document
Orchestrators such as docker, kubernetes, mesosphere, and nomad: Derive applications tags that describe the role of the application, container image data
1
2
3
I II III
Identity
Identity
Identity
Infrastructure
Private Cloud
Private Cloud
Every time a workload initiates a request to another workload, cryptographic identity is used to first authenticate both endpoints and then authorize the request with a local policy. Any other requests are implicitly denied.
Strong portable policies that are abstracted from the underlying IP infrastructure.
Policies can be codified for automation.
Attributes from these sources serve as strong machine generated identity and
are less prone to human errors.
With cryptographic workload identity, we can now build:
www.aporeto.com
Cloud provider instance data
What is theworkload running
User who launchedworkload
Application Tags/Labels
Workload
E-W traffic segmentation between workloads in hybrid cloud or heterogeneous environments. Traversing multiple IP domains is no longer an issue since IP is no longer an identifier.
We are utilizing a whitelist approach which is very scalable because the use of an identity turns policy enforcement into and order N problem and no longer an N^2 problem.
Getting visibility for your applications across heterogeneous environments now becomes a possibility since you have a common workload identifier that is abstracted from infrastructure.
Dynamic containerized applications now have a trusted identity that can be used for security policy enforcement while allowing seamless microservice replication, load-balancing, and rescheduling. Access to microservice APIs can also be restricted with this trusted identity.
This unique approach resolves all the issues we highlighted earlier:
I
II
III
IV
www.aporeto.com
Thank you.
www.aporeto.comCloud-Native Security