3.1 Cloud Infrastructures Flashcards
Cloud responsibility matrix
IaaS, PaaS, SaaS, etc.
– Who is responsible for security?
* Security should be well documented
– Most cloud providers provide a matrix of
responsibilities
– Everyone knows up front
* These responsibilities can vary
– Different cloud providers
– Contractual agreements
– Responsibility matrix example
Hybrid considerations
Hybrid cloud
– More than one public or private cloud
– This adds additional complexity
* Network protection mismatches
– Authentication across platforms
– Firewall configurations
– Server settings
* Different security monitoring
– Logs are diverse and cloud-specific
* Data leakage
– Data is shared across the public Internet
Third-party vendors in the cloud
You, the cloud provider, and third parties
– Infrastructure technologies
– Cloud-based appliances
* Ongoing vendor risk assessments
– Part of an overall vendor risk management policy
* Include third-party impact for incident response
– Everyone is part of the process
* Constant monitoring
– Watch for changes and unusual activity
Infrastructure as code
Describe an infrastructure
– Define servers, network, and applications as code
* Modify the infrastructure and create versions
– The same way you version application code
* Use the description (code) to build other application
instances
– Build it the same way every time based on the code
* An important concept for cloud computing
– Build a perfect version every time
Serverless architecture
Function as a Service (FaaS)
– Apps are separated into individual, autonomous functions
– Remove the operating system from the equation
* Developer still creates the server-side logic
– Runs in a stateless compute container
* May be event triggered and ephemeral
– May only run for one event
* Managed by a third-party
– All OS security concerns are at the third-party
Microservices and APIs
Monolithic applications
– One big application that does everything
* Application contains all decision making processes
– User interface, business logic, data input and output
* Code challenges
– Large codebase, change control challenges
* APIs - Application Programming Interfaces
* API is the “glue” for the microservices
– Work together to act as the application
* Scalable - Scale just the microservices you need
* Resilient - Outages are contained
* Security and compliance - Containment is built-in
Physical isolation
Devices are physically separate
– Air gap between Switch A and Switch B
* Must be connected to provide communication
– Direct connect, or another switch or router
* Web servers in one rack
– Database servers on another
* Customer A on one switch, customer B on another
– No opportunity for mixing data
Physical segmentation
Separate devices
– Multiple units, separate infrastructure
Logical segmentation with VLANs
Virtual Local Area Networks (VLANs)
– Separated logically instead of physically
– Cannot communicate between VLANs without a Layer
3 device / router
SDN (Software Defined Networking)
Networking devices have different functional
planes of operation
– Data, control, and management planes
* Split the functions into separate logical units
– Extend the functionality and management of
a single device
– Perfectly built for the cloud
* Infrastructure layer / Data plane
– Process the network frames and packets
– Forwarding, trunking, encrypting, NAT
* Control layer / Control plane
– Manages the actions of the data plane
– Routing tables, session tables, NAT tables
– Dynamic routing protocol updates
* Application layer / Management plane
– Configure and manage the device
– SSH, browser, API
Attacks can happen anywhere
Two categories for IT security
– The on-premises data is more secure!
– The cloud-based data is more secure!
* Cloud-based security is centralized and costs less
– No dedicated hardware, no data center to secure
– A third-party handles everything
* On-premises puts the security burden on the client
– Data center security and infrastructure costs
* Attackers want your data - They don’t care where it is
On-premises security
Customize your security posture
– Full control when everything is in-house
* On-site IT team can manage security better
– The local team can ensure everything is secure
– A local team can be expensive and difficult to staff
* Local team maintains uptime and availability
– System checks can occur at any time
– No phone call for support
* Security changes can take time
– New equipment, configurations, and additional costs
Centralized vs. decentralized
Most organizations are physically decentralized
– Many locations, cloud providers, operating systems, etc.
* Difficult to manage and protect so many diverse systems
– Centralize the security management
* A centralized approach
– Correlated alerts
– Consolidated log file analysis
– Comprehensive system status and maintenance/patching
* It’s not perfect
– Single point of failure, potential performance issues
Virtualization
Virtualization
– Run many different operating systems on
the same hardware
* Each application instance has its own
operating system
– Adds overhead and complexity
– Virtualization is relatively expensive
Application containerization
Container
– Contains everything you need to run an application
– Code and dependencies
– A standardized unit of software
* An isolated process in a sandbox
– Self-contained
– Apps can’t interact with each other
* Container image
– A standard for portability
– Lightweight, uses the host kernel
– Secure separation between applications
