Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
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).