New IBM Cloud security features you should know

Custom role for operating Code Engine

Cybersecurity is always in a state of change. There are new security features and new attack methods - or was it the other way? Over the past months, several new security features were added to IBM Cloud. In this blog post, I want to quickly describe them and point you to IBM Cloud blog posts where I discuss them in greater detail.

Custom Roles

To access resources in an IBM Cloud account, a user, service ID or trusted profile needs the proper authorization. For that, you must check the assigned, existing privileges against the required ones. With IBM Cloud IAM (Identity and Access Management), the privileges refer to the type of action that is performed. Hence, you often read about actions that are mapped to roles. There are predefined platform roles or service roles. And you can define custom roles that even can combine privileges on the platform and service level.

In the blog post "Reduce Your Attack Surface by Using Custom Roles", I discuss how to utilize custom roles with IBM Cloud. It includes a more detailed introduction and a use case in which I scope access for shared DevOps API keys. By limiting access to the bare minimum, I can reduce the risk from leaked API keys.

Context-based Restrictions

Context-based restrictions provide the ability to define and enforce access restrictions based on the network location ("context") of access requests. Contexts are defined by the type of endpoint or a network zone (or a combination of those). A rule links a context to a resource. When the rule is enabled, only requests that match the context are allowed to proceed to other authorization checks. Because CBRs complement Identity and Access Management (IAM) policies, they are an important building block towards a zero trust architecture. Even if your credentials are leaked or IAM policies misconfigured, CBRs still enforce access and may scope allowed requests to your compute resources or corporate networks.

In the blog post "Towards Zero Trust with Context-Based Restrictions", I look at a scenario in which I only want to allow accecss to my Cloud Object Storage (COS) buckets from scripts running in a Code Engine environment. All other requests should be filtered out and blocked (see diagram below).

Only allow access from Code Engine to the Cloud Object Storage bucket

Inactive Identities

Last, but not least, maintaining an account by regularly cleaning up unused resources and identities (users, service IDs, trusted profiles) helps to control costs and improve security. The IBM Cloud IAM Identity Services API provides functions to manage API keys and tokens, service IDs and trusted profiles, and it provides activity reports to identify inactive identities.

In the blog post "Cloud Security: Identify Inactive Identities", together with my colleague Dimitri Prosper, we show how you can either create your own reports to identify unused API keys and identities or utilize the reporting feature.

Details on an API key used for the Activity Tracker and data backups

 

Conclusions

There are new security features provided by IBM Cloud that help to control who has access to your resources and from where. They allow to work towards a zero trust architecture, to minimize the number of privileges granted, and to identify unused identities.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.