Alexandr Mitiuc - Fotolia
Build up your SDDC security with 3 components
If you want to build a foundation for secure operations in your SDDC, software patches, account privileges and encryption should all be part of your security framework.
Implementing a software-defined data center can lead to flexible resource management and application provisioning, but it can also complicate your organization's information security. As you develop your security strategy, you must keep software layer vulnerabilities, role access capabilities and storage encryption in mind.
The abstraction layer that allows organizations to create a software-defined architecture also adds an extra layer of complexity over a traditional physical data center. A fundamental rule of cybersecurity is that as complexity increases, so does the chance of a vulnerability.
The best way to mitigate this problem is to incorporate all the layers of your software-defined data center (SDDC) -- operating systems, hypervisor memory and virtual servers -- into your patch management strategy. You should apply any available patches as quickly as is practical within your organization's update framework to bolster SDDC security. Also, ensure that your IT department has practices in place to regularly check for patch and version updates.
Because hackers know when new patches are available, they can easily identify unpatched systems that contain known vulnerabilities, and they will work to exploit unpatched vulnerabilities as quickly as possible.
User account security measures
Another common threat to SDDC security is a privileged account, such as Unix root or Windows administrator accounts. These accounts can be compromised and give a hacker free reign in your systems. One way to prevent this is by enforcing secure password use and requiring multifactor authentication wherever possible.
There are two main ways you can help prevent a compromised account.
First, create a dedicated Active Directory forest that solely provides authentication services for your SDDC infrastructure. You should join your hypervisors, management servers and any other low-level infrastructure components to a forest-level domain to get certain permissions. Using Active Directory-based authentication can make it easier to audit privileged account usage across your SDDC.
Second, use single-purpose service accounts rather than having one service account for the whole SDDC. When you use one service account for multiple purposes, the account begins to accumulate more privileges than are necessary for any one task. This is dangerous because if the account is compromised, the attacker will have extensive account privileges at his disposal.
This principle also applies to administrative accounts. Rather than granting the IT staff unrestricted administrative access, use role-based access controls to limit the scope of each privileged account. If IT staff members need high-level administrative permissions, consider creating a series of lesser-privileged accounts instead of granting all the required privileges to a single account.
Storage as an SDDC security component
Accessing storage is also a potential vulnerability for SDDC security because a software layer manages storage resources. An attacker may be able to gain unrestricted access to your storage in spite of other safeguards that you may have put in place. Fortunately, you can mitigate this issue using authentication and encryption.
In addition, be sure to require bidirectional authentication if you are using iSCSI storage. The system should require host authentication before mounting the iSCSI target. At the same time, hosts should require a Challenge-Handshake Authentication Protocol to prevent rogue connections.
You should also include encryption for data at rest and data in motion. Protection for data at rest means encrypting the storage volume. If the volume contains virtual hard disks, then you should encrypt the contents of those virtual hard disks.
Use a dedicated network segment, virtual local area network or IPsec encryption to protect data in motion.