IBM Cloud Security
Intro
This part of the series focuses solely on the security perspective of the IBM Cloud platform. We will go through the main aspects of user and account management, encryption specifics, and availability.
All aspects of security cannot be encompassed in a short article, so we are describing a few challenges that we met along the way.
Access and IAM
Resource groups
As said many times before, plan your IBM Cloud access carefully. In order to start that, you should get acquainted with the principles of the resources groups.
Resource groups are a convenient way to organize the deployed IBM Cloud services. Be careful, as once you deploy an IBM Cloud resource within a resource group, you will not be able to change this afterwards.
Let’s assume your plan to deploy to the main environment within the IBM Cloud platform. First would be a test and development environment, where you prepare your software product before launching it in the preprod and prod environment.
This usually means that access of the development team is limited to the test environment, while access to preprod and prod is far stricter and limited to a few people on the team.
By organizing your IBM Cloud resources into groups, you will find it really easy afterwards to provide access to whole teams, organized within so called access groups.
Access groups
Access groups are used to organize users within a logical access unit. From the above example, you would like to encompass all engineers in the software development team for instance in a R&D access group, so you can provide access to the R&D access group to the test&dev resource group.
Users and Type of Access
When we get to the more specific user or access group element of IBM Cloud is where the platform’s Identity and Access Management (IAM) really shines.
It is incredibly granular and easy to use. You can give different types of access to user, access groups to single services, resources or defined resource groups.
Access divides into a few main categories – Platform Access and Service Access.
Let’s say you would like to provide access to a group from your team that handles monitoring of resources (monitoring access group) to IBM Cloud Monitoring with Sysdig.
The access to the service itself can have multiple layers – Reader/Writer/Manager and they all define the access to the service itself. In addition, access can be assigned only to specific instances from the service or to all instances related to SysDig in the example.
Platform access defines how you manage the service itself – whether you can deploy new instances, add new users with specific access and provide access of other services to it.
Service-to-Service Access
Moreover, IBM Cloud defines in an intuitive way the access from one IBM Cloud service to another. Below we will discuss more services like Key Protect, which require a specific type of access to IBM Object Storage for instance in order to be able to manage keys on encrypted template images.
While it might take a bit to get used to, this also works in an intuitive and transparent way, giving you a very powerful tool to manage the access to your environments.
Classic infrastructure access
Here is where you manage the access to your instances. Be certain that you have enabled SSL VPN connectivity to the user, otherwise you will not be able to access IBM Cloud interface via VPN. VPN unfortunately uses Internet Explorer as the only acceptable browser, which is obviously not a great idea, however, there are other tools, with which to replace logging in via the browser itself.
If you need your team to see the instances created on the IBM Cloud interface, you will have to give them access here or select the option that they see all instances including ones, that you will create in future.
Encryption
Encryption is always key when you start implementing a project onto a public cloud environment. What is really important here, is that IBM Cloud provides encryption for almost all of its services.
Block storage, which is the mainly used iSCSI-attached storage for virtual instances, is supplier encrypted and uses the following algorithms:
- Industry-Standard AES-256 encryption
- Keys are managed in-house with industry standard Key Management Interoperability Protocol (KMIP)
- Storage is validated for Federal Information Processing Standard (FIPS) Publication 140-2, Federal Information Security Management Act (FISMA), Health Insurance Portability and Accountability Act (HIPAA). Storage is also validated for Payment Card Industry (PCI), Basel II, California Security Breach Information Act (SB 1386), and EU Data Protection Directive 95/46/EC compliance.
This also includes Encryption-at-Rest for Snapshots and Replicated storage.
If you need to use a custom key and manage via a key management service like Key Protect, this is also possible.
Local “SAN” drives of instances come unencrypted by default so you would need to create a custom encrypted image and deploy your instances from it. We tend to use vhd-util tool and encrypt images using 512-bit AES with a 512-bit key length.
For key management, we integrate with IBM Cloud Key Protect Service, which has HSM Encryption Certification – FIPS 140-2 Level 3 compliance. Key Protect works really stable out of the box, just make sure you provide the right access to the Object Storage service, as templates first go through Object Storage before being integrated into IBM Cloud interface and used for deployment of instances.
Backup – IBM Cloud Backup (comes standard as eVault implementation) allows once again encryption with a custom key. Third party solutions like Veeam use their own keys and handle key management service themselves.
For instance, Veeam reads VM or file data, encodes data blocks, transfers them to the target side in the encrypted format and stores the data to a file in the backup repository.
For network traffic encryption, Veeam Backup & Replication uses the 256-bit Advanced Encryption Standard (AES).
To encrypt data blocks in backup files and files archived to tape, Veeam Backup & Replication uses the 256-bit AES with a 256-bit key length in the CBC-mode.
To generate a key based on a password, Veeam Backup & Replication uses the Password-Based Key Derivation Function, PKCS #5 version 2.0. Veeam Backup & Replication uses 10,000 HMAC-SHA1 iterations and a 512-bit salt.
Veeam Backup & Replication uses different encryption keys for every job session.
Veeam Backup & Replication uses the following hashing algorithms:
- For digital signature generation: SHA-1, SHA-256
- For HMAC generation: HMAC_SHA-1
- For random number generation: SHA-1
Additionally, the way we are setting it up in most of the cases, all backups are placed on IBM Cloud block storage, which is encrypted as shown above.
Availability
We touched the topic in the previous post on instances, so I will just briefly discuss it here. An intrinsic part of your security implementation is by all means the availability of the resources that you use. Be sure to have standby services to kick in for your primary ones, as unfortunately, IBM Cloud does not always reach maximum availability on the hypervisor level. There might be a time that you would lose a server, which could be really critical for you . Make sure you always have some scenario to secure your environment in such cases.
Conclusion
IBM Cloud can be a secure implementation, if planned and implemented correctly . There can be some hurdles on the way, however, once you master the integration with Key Protect and the user access mechanism, you should be able to have a pretty stable security implementation.
If you still need some assistance during the process, check our services here, or contact us.
Note: L3C is not aligned to any particular public cloud provider and is an independent cloud services provider. This blog is solely to share our experience and is based on real implementations.
