Management Plane and Business Continuity

management plane = Cloud Configuration GUI

Thus, gaining access to the management plane is like gaining unfettered access to your data center, unless you put the proper security controls in place to limit who can access the management plane and what they can do within it.

• The cloud provider is responsible for ensuring the management plane is secure and necessary security features are exposed to the cloud user, such as granular entitlements to control what someone can do even if they have management plane access.
• The cloud user is responsible for properly configuring their use of the management plane, as well as for securing and managing their credentials.

No matter the platform or provider there is always an account owner with super-admin privileges to manage the entire configuration. This should be enterprise-owned (not personal), tightly locked down, and nearly never used.

All privileged user accounts should use multi-factor authentication (MFA). If possible, all cloud accounts (even individual user accounts) should use MFA. It’s one of the single most effective security controls to defend against a wide range of attacks.

Recommendations

• Management plane (metastructure) security
  • Ensure there is strong perimeter security for API gateways and web consoles.
  • Use strong authentication and MFA.
  • Maintain tight control of primary account holder/root account credentials and consider dual-authority to access them.
    • Establishing multiple accounts with your provider will help with account granularity and to limit blast radius (with IaaS and PaaS).
  • Use separate super administrator and day-to-day administrator accounts instead of root/primary account holder credentials.
  • Consistently implement least privilege accounts for metastructure access.
    • This is why you separate development and test accounts with your cloud provider.
  • Enforce use of MFA whenever available.
• Business continuity
  • Architecture for failure.
  • Take a risk-based approach to everything. Even when you assume the worst, it doesn’t mean you can afford or need to keep full availability if the worst happens.
  • Design for high availability within your cloud provider. In IaaS and PaaS this is often easier and more cost effective than the equivalent in traditional infrastructure.
    • Take advantage of provider-specific features.
    • Understand provider history, capabilities, and limitations.
    • Cross-location should always be considered, but beware of costs depending on availability requirements.
      • Also ensure things like images and asset IDs are converted to work in the different locations.
    • Business Continuity for metastructure is as important as that for assets.
  • Prepare for graceful failure in case of a cloud provider outage.
    • This can include plans for interoperability and portability with other cloud providers or a different region with your current provider.
  • For super-high-availability applications, start with cross-location BC before attempting cross-provider BC.
  • Cloud providers, including private cloud, must provide the highest levels of availability and mechanisms for customers/users to manage aspects of their own availability.

---

🌱 Back to Garden