Contenu connexe
Similaire à Delivering Secure OpenStack IaaS for SaaS Products - OpenStack 2012.pptx (20)
Plus de OpenStack Foundation (20)
Delivering Secure OpenStack IaaS for SaaS Products - OpenStack 2012.pptx
- 1. Delivering Secure
OpenStack IaaS for SaaS
Products
Andrew Hay
Chief Evangelist
andrew@cloudpassage.com
twitter.com/andrewsmhay
OpenStack Summit 2012
© 2012 CloudPassage Inc. #cloudsec | #openstack
- 2. Who are you?
• Andrew Hay, Chief Evangelist, CloudPassage
• Former
– Industry Analyst @ 451 Research
– Information Security Office @ UofL and bank in Bermuda
– Product, Program and Engineering Manager @ Q1 Labs
– Linux guy at a few ISPs
© 2012 CloudPassage Inc.
- 3. What does CloudPassage do?
Security and compliance automation for
public, private and hybrid cloud servers
Dynamic Cloud System Integrity
Firewall Automation Monitoring & IDS
Two-Factor Server Account
Authentication Management
Server Vulnerability Server Security
Scanning Events & Alerting
Eliminates barriers to cloud hosting adoption
Enables cloud hosting & IaaS compliance
Purpose built for cloud from the ground up
© 2012 CloudPassage Inc.
- 4. Topics for today
Overview of OpenStack security
OpenStack host security
Why the cloud makes security hard
How to secure OpenStack images
© 2012 CloudPassage Inc.
- 6. OpenStack Security: Quantum
• Quantum
– Network connectivity as a service
– From a flat, shared network to per-tenant routers with private
networks
– API to let 3rd party vendors „plug in‟
• e.g. Nicera Network Virtualization Platform (NVP)
– Supports virtual port isolation, virtual port mirroring, QoS, security
profiles and detailed per-port statistics.
© 2012 CloudPassage Inc.
- 7. OpenStack Security: Keystone
• Keystone
– Identity service used by OpenStack for authentication (authN)
and high-level authorization (authZ)
– Currently supports token-based authN and user-service
authorization.
– Recently re-architected to allow for expansion to support
proxying external services and AuthN/AuthZ mechanisms
• e.g. oAuth, SAML and openID in future versions.
keystone user-create --name=nova
--pass=Sekr3tPass
--tenant_id=[the uuid of the tenant]
--email=nova@nothing.com
© 2012 CloudPassage Inc.
- 8. OpenStack Security: Nova
# This is the code for the python-keystoneclient script
• Nova
# Using token auth env variables
export SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/
export SERVICE_TOKEN=secrete_token
– Security
keystone user-list groups $ nova secgroup-create openpub "Open for public"
keystone tenant-create --name=demonova secgroup-add-rule openpub icmp -1 -1 0.0.0.0/0
$
– Firewall (iptables) $ nova secgroup-add-rule openpub tcp 22 22 0.0.0.0/0
# Using token auth flags
keystone --token=secrete --endpoint=http://127.0.0.1:5000/v2.0/ user-list
keystone --token=secrete --endpoint=http://127.0.0.1:5000/v2.0/ tenant-create --
name=demo
# nova-manage network create --num_networks=100 --
– VLAN‟s fixed_range_v4=172.16.100.0/24
# Using user + password + tenant_name env variables
export OS_USERNAME=admin
export OS_PASSWORD=secrete
export OS_TENANT_NAME=admin
keystone user-list
keystone tenant-create --name=demo
# Using user + password + tenant_name flags
keystone --username=admin --password=secrete --tenant_name=admin user-list
keystone --username=admin --password=secrete --tenant_name=admin tenant-create --
name=demo
– Identity Management with Keystone
© 2012 CloudPassage Inc.
- 10. Why Secure the Images?
• “We have security groups, infrastructure firewall
rules and Keystone for authentication so we don’t
need to secure the images.” – OpenStack Admin
with a Plan.
“Everyone has a plan
'till they get punched
in the mouth.” – Mike
Tyson
© 2012 CloudPassage Inc.
- 11. Why Secure the Images?
• Network-based security is only so good in
multitenant clouds
• The ultimate target is the endpoint
– So secure it
• You wouldn‟t leave your doors unlocked…
– Would you?
© 2012 CloudPassage Inc.
- 12. Why Secure the Images?
“Son, we live in a world that has
walls, and those walls have to be
guarded by men with guns. Who's
gonna do it? You? You, Lt.
Weinburg?”
© 2012 CloudPassage Inc.
- 13. No “Natural” Segmentation
Auth DB DB DB
Server
core core
Firewal
l
Load App Load App
Balancer Server Balancer Server
dmz dmz
Firewal
l
public cloud
© 2012 CloudPassage Inc.
- 14. Cloud Servers are More Exposed
Load
Balancer
App App
Server Server
DB
Master
public cloud
© 2012 CloudPassage Inc.
- 15. DENY ALL – Helps & Hinders
&$#@$*@?
Load !?!?
Balancer
FW
App App
Server Server
FW FW
DB
Master
FW
public cloud
© 2012 CloudPassage Inc.
- 16. What About Complex Deployments?
Load Load
Balancer Balancer
FW FW
App App App
Server Server Server
FW FW FW
DB DB
Master Slave
FW FW
public cloud
© 2012 CloudPassage Inc.
- 17. What About Dynamic Deployments?
Load Load
Balancer Balancer
FW FW
App App App
Server Server App
Server
FW FW Server FW
IP
DB DB
Master Slave
FW FW
public cloud
© 2012 CloudPassage Inc.
- 18. From De-Provisioned to AHHH!!!
Load Load
Balancer Balancer
FW FW
App App
Server Server App
FW FW Server
IP
DB DB
Master Slave
FW FW
public cloud
© 2012 CloudPassage Inc.
- 20. Imagine There‟s No Network
• It‟s easy if you try…
• We should protect our servers as if
they are directly connected to the
Internet
– Because in some cases, they are.
© 2012 CloudPassage Inc.
- 21. Why secure the OS?
• A hardened OS often is the last line of
defense in the event of a security
compromise.
• It is important to note that hardening is
not a panacea for security.
– It is just another layer in a good security
model.
• By definition, any machine that is
accessible on a network and running
services is potentially insecure.
– (i.e. pretty much any server)
© 2012 CloudPassage Inc.
- 22. Top 5 Easy Things to Start
Securing Your OpenStack Images
1. Disable unnecessary services
2. Remove unneeded packages
3. Restrict access to sensitive files & directories
4. Remove insecure/default configurations
5. Allow administrative access ONLY from trusted
servers/clients
© 2012 CloudPassage Inc.
- 23. Disable unnecessary services
• Only what is needed…is needed
• Shutdown and disable
unnecessary services
– e.g. telnet, r-services, ftpd, etc.
© 2012 CloudPassage Inc.
- 24. Remove unneeded packages
• If it isn‟t being used…why keep it?
• If the server doesn‟t need to
serve web pages
– Remove PHP, Apache/nginx
• If it‟s not a database server
– Remove MySQL/PostgreSQL
© 2012 CloudPassage Inc.
- 25. Restrict access to sensitive files & directories
• Protect what‟s important from prying/malicious eyes
• Ensure file permissions restrict access to
sensitive files and directories
– E.g. /etc/shadow, /etc/ssh/sshd_config,
– E.g. /var/tmp/, /tmp/
© 2012 CloudPassage Inc.
- 26. Remove insecure/default configurations
• Disable password authentication for SSH
– Force public key authentication
– Also, disable empty passwords for users
• SSH
– Ensure only v2 protocol connections are allowed
• Apache
– Minimize loadable modules
– Disable ServerTokens and ServerSignature directives
© 2012 CloudPassage Inc.
- 27. Allow administrative access ONLY from trusted
servers/clients
• Leverage the firewall and other tools
– Source of corporate network / admin
network range
– 3rd-party tools like fail2ban
• Don‟t allow „server hopping‟
– Most people use keys without passwords to
make things easier
• Facilitate on-demand access using two-
factor authentication
© 2012 CloudPassage Inc.
- 28. What do we want?
Security
Security !
!
Bieber!
© 2012 CloudPassage Inc.
- 29. When do we want it?
Now!
Now!
Bieber!!
!!
© 2012 CloudPassage Inc.
- 30. How do we get it?
Ummm..
Er, ah?
Kidnap!
© 2012 CloudPassage Inc.
- 32. If only we had more time…
• More documentation to review:
– NIST SP800-123: Guide to General Server Security
• http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf
– Halo Configuration Policy Rule Checks
• http://support.cloudpassage.com/entries/22033142-configuration-policy-rule-
checks
– CIS Red Hat Enterprise Linux 6 Benchmark v1.1.0
• http://benchmarks.cisecurity.org/en-us/?route=downloads.show.single.rhel6.110
– NSA Security Configuration Guides
• http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operatin
g_systems.shtml#linux2
© 2012 CloudPassage Inc.
- 33. Number 6 – Employ Tools Designed for
Cloud Environments
• You‟ve locked down your server
based on the Top 5
– And other guides
• Now What?
• Rely on a tools built for continuous
cloud security:
Dynamic Cloud Server Vulnerability Server Account
Firewall Automation Scanning Management
Two-Factor
System Integrity Server Security
Authentication
Monitoring & IDS Events & Alerting
© 2012 CloudPassage Inc.
- 34. Summary
Cloud deployments require a
new approach to security
Get your house in order before
adding tools on top
Use tools that work on/with/in
cloud environments
© 2012 CloudPassage Inc.
- 35. Summary++
• Don‟t be in such a rush to get to cloud that you trip
yourself up…
© 2012 CloudPassage Inc.
- 36. Try Halo FREE - 5 Minute Setup
Register at Free
Trial!
cloudpassage.com
Install daemons on cloud
servers
Configure security policies
in Halo web portal
© 2012 CloudPassage Inc.
- 38. The End
• Ask questions!
– Lots more info: community.cloudpassage.com
– Small bits of info: @cloudpassage
• Tell me what you think!
– Email: andrew@cloudpassage.com
– Twitter: @andrewsmhay
BTW,
• We’re hiring! We’re
Sales Engineers, cloud/security Hiring!
analysts, rails devs and UX devs
– Email: jobs@cloudpassage.com
© 2012 CloudPassage Inc.
- 39. Thank You!
Andrew Hay
andrew@cloudpassage.com
@andrewsmhay
@cloudpassage
#CloudSec | #OpenStack
© 2012 CloudPassage Inc.