,欢迎您!
登录您的红帽帐户
尚未注册?下面是您应该进行注册的一些理由:
- 从一个位置浏览知识库文章、管理支持案例和订阅、下载更新以及执行其他操作。
- 查看组织内的用户,以及编辑他们的帐户信息、偏好设置和权限。
- 管理您的红帽认证,查看考试历史记录,以及下载认证相关徽标和文档。
您可以使用红帽帐户访问您的会员个人资料、偏好设置以及其他服务,具体决取决于您的客户状态。
出于安全考虑,如果您在公共计算机上通过红帽服务进行培训或测试,完成后务必退出登录。
退出红帽博客
Blog menu
Welcome to another post dedicated to the use of Identity Management (IdM) and related technologies in addressing the Payment Card Industry Data Security Standard (PCI DSS). This specific post is related to requirement three (i.e. the requirement to protect stored cardholder data). In case you're new to the series - the outline and mapping of individual articles to the requirements can be found in the overarching post that started the series.
Section three of the PCI DSS standard talks about storing cardholder data in a secure way. One of the technologies that can be used for secure storage of cardholder data is
disk encryption called LUKS. But LUKS keys also need to be managed (as mentioned in requirement 3.6.3). One potential solution: IdM's Vault – a secret store that can be used to escrow disk encryption passwords and implement policies and conditions for the recovery of such passwords (or keys). While in a Vault, the keys and passwords do not need to be in any way related to keys and passwords used by users that access the cardholder services; requirement 3.4.1 is thus fully met by this solution.
Requirement 3.5.3 creates a challenge demanding separation of keys. This usually leads to the need to involve a user to unlock their key to start a process. For example, a system volume can be encrypted but in case of a reboot an administrator has to come over and enter a password to continue the boot process. A new technology called Network Bound Disk Encryption addresses this problem by placing a special server on the network. While this technology is not currently included with Red Hat Enterprise Linux - here is a pointer to a demo.
Questions about how Identity Management relates to requirement three? Reach out using the comments section (below).