6. Management Plane & business continuity - DONE Flashcards
Reminder what is the metastructure and what is the management plane?
The management plane is the most important area that you need to secure tightly and it is solely your responsibility to secure access to it.
”
the metastructure is the virtual world for which you need virtual tools. The management plane is the area where the virtual infrastructure of your cloud is built, configured, and destroyed. Remember that the management plane is a part of the metastructure. The management plane is your single interface to view, implement, and configure all of your resources in this virtual world.
you (or anyone) can connect to the management plane supplied by a cloud provider across the Internet using APIs or web browsers.
Anyone with full access to the management plane quite simply has the power to build or destroy anything in your virtual world. Proper implementation and management of restricting access to the management plane is job number 1 as far as securing any cloud implementation.
“As you know, the cloud is a shared responsibility model, and this applies to the management plane as well.”
The provider is responsible for building a secure management plane for you to access, and you are responsible for ensuring that only appropriate people have appropriate qualifications to manage your virtual world and that every user has least privileges, and nothing more, to do only what they need to do.
The management plane is often accessible via multiple methods. In general, you can expect to have access to command-line interface (CLI) tools, a web interface, or APIs.
When you’re considering these different access methods from a security perspective, be aware that quite often different credentials will be involved.
What credentials are needed for the web browser?
For example, when you’re connecting via the web browser, standard credentials such as a username and password are generally used. These credential sets can be stored within the cloud provider’s environment, or you can use identity federation to keep the credentials on your side and not on the provider’s side.
The management plane is often accessible via multiple methods. In general, you can expect to have access to command-line interface (CLI) tools, a web interface, or APIs.
When you’re considering these different access methods from a security perspective, be aware that quite often different credentials will be involved.
What credentials are needed for the API?
accessing via the API generally uses either HTTP request signing or the OAuth protocol
Some providers will use an access key and secret access key as the credentials as part of authenticating and signing REST requests. The access key itself acts like your username, and the secret access key is like your password. Behind the scenes, the secret access key is used to sign the request.
Think of the API as being the engine that runs everything. Whether you use the web interface, the CLI, or any SDK, you’re likely having your request translated to the provider API, and that, in turn, is executed at the provider.
“You can generally consider that anything available via the web console will also be available via the API. If something is exposed via an API, it can be accessed programmatically. And if it can be accessed programmatically, it can be automated. A provider may offer some functionality to either method first, but these encounters should be rare with any established provider.”
When you first register with a cloud provider, you will create an initial account that is considered the master account (some providers may call this the root account).
This account needs to be tightly locked down and used only to establish proper identity and access management. Here is some guidance regarding the creation and securing of this initial master account:”
- Create the account using a unique corporate e-mail address. This e-mail address will be the user ID for the master account and may serve as how your provider will engage with your company. This account should never be created by someone using their personal e-mail address or corporate e-mail address.
2.Set up a distribution list for this master account e-mail. This will prevent several problems (e.g., the original creator leaves the company and all e-mails wind up in /dev/null [a UNIX term for a garbage bin], or someone vital doesn’t see an urgent message from the provider).
3.Establish a strong password that meets your security policy and establish multifactor authentication (MFA). Many providers will support the time-based one-time password (TOTP), a temporary passcode generated by an algorithm that uses the current time of day as one of its authentication factors. Other providers may support a newer MFA method, Universal 2nd Factor (U2F), a safer MFA method than TOTP.
When you first register with a cloud provider, you will create an initial account that is considered the master account (some providers may call this the root account).
This account needs to be tightly locked down and used only to establish proper identity and access management. What is the last step you do once the account, password and MFA for the master account are set up?
you need to set up a new super-admin account you can use to access the management plane. Once that’s done, you should write down the master account logon ID and password, put them in an envelope along with the MFA device, and lock these in a safe. From this point forward, the master account should be used only in emergencies, and all activity performed should use appropriate accounts.
How will you secure the management plane properly?
“To secure the management plane properly, you need two things:”
a solid plan of who is allowed to do what (entitlements) and a provider that has a robust identity and access management (IAM) system that supports identification, authentication, and authorization with appropriate granularity.
This granularity will enable you to implement a least-privilege approach to restrict who is permitted to perform specific actions in your cloud environment.
So far we have been looking at what the customer can do to secure their use of the management plane. What should the provider focus on when building the management plane, and what should customers be inspecting prior to using a provider?
*Perimeter security - How has the provider implemented controls to protect its network from attacks, both lower-level network defences and the application stack, for both web consoles and API gateways?
*Customer authentication - Does the provider allow the use of MFA? What types of MFA are supported, and what systems in the provider’s environment can use MFA? Does the provider support cryptographically secure methods of authentication such as OAuth or HTTP request signing?
*Internal authentication and credential passing - How does the provider allow for access within the environment? Do they support temporary credentials through the” “implementation of IAM roles, for example?
*Authorization and entitlements - How granular are the permissions that customers can use to support the least privilege? Does the provider simply grant anyone logging on with administrative privileges? If so, you won’t be able to create job-specific permissions
*Logging, monitoring, and alerting - How can you collect artefacts of compliance if you have no ability to log failed and successful logins, or to log what actions are taken by particular IAM accounts? The ability to log actions can lead to the discovery of malicious actions, and if appropriate orchestration is possible in the environment, this can be used to support event-driven security to lower response times to seconds thanks to automated response capabilities.
What is architecting for failure?
“If you fail to plan, you plan to fail. BCP/DR in the cloud is like everything else we’ve covered in this book, in that it involves a shared responsibility. The provider gives you the tools for DR, but you need to perform the BIA to understand the critical systems and implement appropriately to meet recovery objectives. That’s what architecting for failure is all about.”
Some companies refer to DR sites in the cloud (IaaS, most appropriately) as a “pilot light” site. If a site is properly planned and continuously tested, you can go from nothing to a completely available site in minutes through the beauty of infrastructure as code (IaC).
What is IaC and what can it do?
What si a benefit of using it?
IaC is essentially the creation (and maintenance) of a script that uses templates that will build anything you want, ranging from networking to systems. Using IaC, you have the ability not only to rebuild a virtual infrastructure programmatically in minutes instead of hours but also to remove the potential of human error that is often introduced when people are under pressure and trying to do things as quickly as possible.
BCP/BR
traditional vs cloud
“BCP/DR in a cloud environment differs from BCP/DR in a traditional IT world, because the cloud environment offers a pay-as-you-go model. Every decision you make has an associated cost and likely additional complexity.
Let’s consider an IaaS example: Implementing BCP/DR in a single region is often easier and less costly than implementing BCP/DR in multiple regions. Providers may charge additional fees to copy data from one region to another, and you may need to create region-specific scripts to reflect changes in asset IDs.
Then there are the jurisdictional challenges, as discussed in previous chapters, and how they may impact BCP/DR legally.
How may BCP/DR be impacted by the IaaS service model?
DR options in IaaS range from running everything in a single data center to using IaC to build an infrastructure very quickly and restoring data from snapshots, to building a secondary hot site in a different geographical region while data is continuously copied from one region to another. How do you determine what is appropriate?
How may BCP/DR be impacted by the Paas service model?
How do you store your data and application code within a provider’s environment? Did you bake encryption into your application, or are you relying on the provider for that service? The answer directly impacts your lock-in potential with a provider. (Vendor lock-in refers to the inability to move from one environment to another without significant effort on the customer side.) Finally, how do you export this data if a provider goes out of business or is sold to another company?
How may BCP/DR be impacted by the Saas service model?
your BCP/DR plans may be as simple as exporting data on a regular basis. When considering SaaS, however, consider data availability. Make sure your provider allows you to export data in a common format at acceptable times to support your RTO/RPO requirements. For example, imagine you have an RTO of one hour, but the provider allows you to export data only once a week. How are you going to meet your RTO if the provider goes bankrupt and stops communicating with you, the latest export is five days old, and data is stored in a proprietary format? How portable is data that can be used only with provider tools when those tools are unavailable?
What is RTO and RPO?
the recovery time objective (RTO) and the recovery point objective (RPO). The RTO is simply the acceptable amount of time required to restore function and is usually measured in hours or days.
The RPO is the acceptable amount of recent data loss that would be tolerated.
