Learn how to remove operational complexity from achieving secure – and easily auditable – user access to your AWS systems. Automate tightly controlled user access in highly dynamic AWS environments. Painlessly report exactly who accessed which resources, from where, and when – in near real-time – and save your teams thousands of hours in audit prep work.
2. Security is kind of a big deal…
HYBRID
ENVIRONMENTS
ON-PREMISES
We’ve all got them. Are we doing the right thing to secure them?
IN THE CLOUD
3. And it’s no different in AWS.
But it’s hard.
Managing tightly-
controlled user access
in AWS is too complex.
And complexity leads to
errors and sloppiness.
4. So why is it so complex?
There are 6 main reasons
5. User access is IP-centric, and
IP addresses change1
Think office to home, to mobile, to a coffee shop, to a plane…
Predicting where users are going
to be when accessing your
network is a very big challenge;
and almost impossible if you
have a mobile workforce.
6. Dynamic environments cause
extra administrative burdens2
As virtual machines and services
within AWS are spun up, expanded or
contracted, being able to dynamically
allocate security policies to these
resources becomes a real challenge.
7. Complexity leads to shortcuts3
A lot of the time shortcuts are
taken that compromise the
security posture in the footprint
of a particular environment.
8. Forced use of VPN connectivity
to manage access control4
And it can create performance
issues for your end users and
force unnecessary hops from
environment to environment
just to ensure that people are
coming at the environment
from appropriate locations.
The use of VPNs is not a trivial task.
VPN
9. Logging correlation complexities
5 All of this hopping around and all of these different technologies
lead to logging correlation issues.
So when it comes to audit and
compliance, you have a tremendously
difficult task on your hands to correlate
these logs and figure out who is doing
what, who is accessing which application,
what time of day and under what context
they are doing it.
10. Shared AWS responsibility model
6
Do you know where
AWS’s responsibility
for the cloud ends –
and yours begins?
12. Customer Data
Client-Side Data Encryption & Data
Integrity Authentication
Server-Side Encryption (File
System and/or Data)
Network Traffic Protection
(Encryption/Integrity/Identity)
CUSTOMER
Platform, Apps, Identity &
Access Management
OS, Network & Firewall
Configuration
You’re responsible
for the security in
the cloud.
13. Anything in the
cloud is your
responsibility.
Anytime you take advantage of the
resources and build virtual machines,
deploy data into S3 buckets or use
a feature like AWS Snowball to push
data into the environment, security
becomes your responsibility.
AWS’s responsibility ends with the
physical components of the cloud…the
data center, the servers, the storage.
You are responsible for everything that
leverages those physical components
– all the configured services, data,
deployed applications. This includes
network access security.
AWS gives you tools, but you have
to implement them.
15. You can use Security
Groups, but they introduce
operational complexity with
negative consequences.
16. We either give wide-open access
and end up with this…
No accountability/
visibility
Increased risk of
security breaches
Managing compliance
is virtually impossible
17. Or tightly controlled access and
end up with this…
Reduced
business agility
Friction for
DevOps
Inefficient
approval process
19. Four users access the
Amazon environment
from a known source.
Security Groups
73.68.25.22124
1
20. Four users access the
Amazon environment
from a known source.
Their public IP address
is the known source.
The security groups are
configured appropriately.
Security Groups
73.68.25.22124
1 2
21. The challenge is when users try to access
from other locations.
Security Groups
73.68.25.22124
22. Tightly control access – force users to
VPN into a known office and through
a 73 dot IP address?
Allow wide
open access
from anywhere?
Security Groups
73.68.25.22124
So which do you do?
23. There’s a better way to do it.
It’s called a Software-Defined Perimeter
24. A Software-Defined Perimeter gives every user on
your network – whether an internal employee or a third-party
working for you – an individualized perimeter around themselves
and the network resources they’re allowed to access.
26. Industry experts suggest using it
“SDP enables organizations
to provide people-centric,
manageable, secure and
agile access to networked
systems.”
“Legacy, perimeter-
based security models are
ineffective against attacks.
Security and risk pros must
make security ubiquitous
throughout the ecosystem.”
“It is easier and less
costly to deploy
than firewalls, VPN
concentrators and other
bolt-in technologies.”
34. The person, their identity,
the device they’re on, the
network they’re connected
to, and just about anything
else you could think of to
analyze before you allow
access resources on your
network, is checked.
73.68.25.22124
35. Once a person is authorized to
view resources, everything else on
the network becomes invisible.
36. Cyxtera delivers a Software-Defined
Perimeter Solution for AWS
AppGate SDP
37. AppGate SDP
Imagine a user wants to access the company’s ERP system
MANAGED NETWORKS
Cloud, On-premises or Hybrid
ERP Secured
Mail
Group File
Share
Executive
Files
Enterprise
Finance
SharePoint ERP
EXEC_
SERVER
DIGITAL
IDENTITY
38. AppGate SDP
First we look at both context and identity.
DEVICE
CUSTOM
ATTRIBUTES
APPLICATION
PERMISSIONS
LOCATION:
HOME
ANTI-VIRUS
TIME
DIGITAL
IDENTITY
39. AppGate SDP
We confirm it matches your policies before granting access.
DEVICE
CUSTOM
ATTRIBUTES
APPLICATION
PERMISSIONS
LOCATION:
HOME
ANTI-VIRUS
TIME
DIGITAL
IDENTITY
40. AppGate SDP
We then create a dynamic
Segment of One
(1:1 firewall rule).
ENCRYPTED & LOGGED
MANAGED NETWORKS
Cloud, On-premises or Hybrid
ERP Secured
Mail
Group File
Share
Executive
Files
Enterprise
Finance
SharePoint ERP
EXEC_
SERVER
DEVICE
CUSTOM
ATTRIBUTES
APPLICATION
PERMISSIONS
LOCATION:
OFFICE
ANTI-VIRUS
TIME
DIGITAL
IDENTITY
41. AppGate SDP
And make everything else (the
applications and the rest of the
network) invisible to the user.
ENCRYPTED & LOGGED
MANAGED NETWORKS
Cloud, On-premises or Hybrid
ERPDEVICE
CUSTOM
ATTRIBUTES
APPLICATION
PERMISSIONS
LOCATION:
OFFICE
ANTI-VIRUS
TIME
DIGITAL
IDENTITY
42. AppGate SDP
And if the user goes home and wants to continue working,
AppGate SDP automatically checks “user-context” again,
and applies the correct “home-based” policy.
ENCRYPTED & LOGGED
MANAGED NETWORKS
Cloud, On-premises or Hybrid
ERPDEVICE
CUSTOM
ATTRIBUTES
APPLICATION
PERMISSIONS
LOCATION:
HOME
ANTI-VIRUS
TIME
DIGITAL
IDENTITY
43. The Result?
Locked-down secured access to AWS resources
that is operationally simple to manage and
maintain. Let’s look at this more closely…
44. AWS Security Groups
We all know about AWS Security
Groups. The current Security
Group model is complicated
and unpredictable.
45. AWS Security Groups & AppGate SDP
Using AppGate SDP, there are multiple gateways, protecting multiple cloud
providers with split functionality.
CURRENT MODEL
46. AWS Security Groups & AppGate SDP
AppGate SDP defines protected destinations, called Entitlements and protects
simple IP addresses and ports, but also ranges of IP addresses and Ports, AWS Tag
and Values as well as AWS Security Group names.
Current Model
47. AWS Security Groups & AppGate SDP
AppGate SDP offers a new Security Model inside AWS, redefining the Security
Group so that protected destinations allow traffic only from the AppGate SDP
Gateway, ensuring all users access those resources through the contextual controls
provided by AppGate SDP.
AppGate SDP Model
48. AWS Security Groups & AppGate SDP
Users are tied to the entitlements through Policies where we can enforce
contextual awareness before allowing specific users access to specific
entitlements. This combination allows us to get very granular on who can
access what and under what circumstances.
AppGate SDP Model
DEVELOPER ACCESS POLICY
• Allow TCP Access
• On Port 22
• For all servers tagged
Dev-Project
• If users are in group
Development
AUTHENTICATION POLICY
• If users are on corporate
network allow Single-Factor
Authentication
• If users are not on
corporate network require
Multi-Factor Authentication
DEVICE POLICY
• Allow access if Anti-Virus
is running
• Allow access if Device
Firewall is enabled
• Allow access if OS patch
level is current
POLICY POLICY POLICY
49. Because there is
just one IP address,
managing security
just got easier.
AppGate SDP Model
50. AppGate SDP from Cyxtera provides user
control, operational agility and compliance
Operational agility is
boosted
Access policies across
hybrid environments are
consistent
Access is tightly secured
with a Segment of One
Compliance reporting
is easier and faster
Infrastructure changes are
dynamically protected
DevOps can work
faster
51. AWS Security…Simplified!
User-centric security policies…because people are not IP addresses
Joe R
Developer
Project Hawk
Sally M
Developer
Project Eagle
Enterprise Headquarters
Coffee Shop
Charles S
DB Admin
Consultant
52. Learn more about AppGate SDP
DATASHET VIDEO
AppGate SDP for AWS
WHITEPAPER
Forrester Report
No More Chewy
Centers:
The Zero Trust Model of
Information Security
AppGate SDP
53. Want to know more?
AWS FREE TRIAL AZURE FREE ACCOUNT
GET IN TOUCH
Click here to get access to a 15-day
free trial of AppGate SDP on AWS
marketplace.
Click here to create and view the benefits
of a Microsoft Azure account, including a
$200 credit towards Azure products.
Email: sales@cyxtera.com Twitter: @Cyxtera LinkedIn: linkedin.com/company/cyxtera