订阅内容

This article is third in a series dedicated to the use of Identity Management (IdM) and related technologies to address the Payment Card Industry Data Security Standard (PCI DSS). This specific post covers the PCI DSS requirement related to not using vendor-supplied defaults for system passwords and other security parameters. The outline and mapping of individual articles to the requirements can be found in the overarching post that started the series.

The second section of the PCI-DSS standard applies to defaults - especially passwords and other security parameters. The standard calls for the reset of passwords (etc.) for any new system before placing it on the network. IdM can help here. Leveraging IdM for centralized accounts and policy information allows for a simple automated provisioning of new systems with

tightened configurations. In addition, Red Hat Satellite 6 and IdM play well together - allowing for automatic enrollment of Linux systems into an IdM managed identity fabric.

Requirements 2.2.3 and 2.3 (also covered in Appendix A2) call for use of different security features like SSH or TLS. Both SSH and TLS require a solution that would provision and manage associated keys. IdM comes to rescue in both cases. For SSH IdM can manage and deliver user and host public keys to the systems joined to the IdM domain. For TLS both the client and server need to have proper certificates and private keys. Where do they come from? How they are tracked and renewed? IdM, together with a client side component called certmonger (integrated with the Linux operating system), allows for provisioning, tracking and rotation of the certificates. These key management aspects of the environment are usually left to the IT professionals to figure out. With IdM and certmonger, certificate management can really become an automated process making environment more secure and less susceptible to a human error or misconfiguration.

TLS is used in many places for many purposes and while automation is great... it's not enough. If certificates are issued by a single certificate authority for multiple environments and use cases there is a chance that a certificate issued for one purpose will be misused to authenticate a different connection. This can be mitigated with fine grained access control rules implemented inside each of the services that accepts TLS based authentication. But this is error prone. Having a certificate authority (CA) for a domain of use would be preferable. Unfortunately creating such CAs is usually a hassle and a cost. This is why the IdM team is working on a solution called subCAs. With just a single command an administrator would be able to create a subCA dedicated to a particular domain of use. Then all the certificates issued by this subCA would be usable only within the context of that specific domain.

Finally, requirement 2.2.4 calls for configuring system security parameters. Once again, IdM, with central management of the host-based-access-control rules, privilege escalation (sudo), and SELinux (for user mapping) provides a relief and help with such configuration.

Questions about how Identity Management relates to requirement two?  Reach out using the comments section (below).


关于作者

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事