This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Add OS support for transparent encryption/decryption of stream files in the IFS
On the database side, IBM provided corresponding tooling when it introduced Db2 for i field procedures in IBM i 7.1. Field procedures allow Db2 data to be transparently encrypted/decrypted by ISV solutions. But corresponding tooling for encryption/decryption of stream files is missing.
Most customers maintain business data both in Db2 and in the IFS. OS support for IFS encryption hence covers a major potential security issue.
Existing ISV solutions for transparent encryption/decryption use the IBM i malware scanning exit points to hook into IFS processing. However, the malware scanning exit points were not designed for this purpose, so ISV solutions have to overcome multiple technical obstacles: - Certain operations on stream files, such as file moves, are not visible to the malware scanning exit points, but have to be taken into account by the encryption solutions. Those operations need to be tracked by using object journaling. Journal entries record information using object IDs; the exit point uses file paths. The journal entries represent a separate, asynchronous source of event-type information, which the ISV solution then must attempt to reconcile with the exit point information and processing. This is especially challenging in high-volume environments. - Individual file-close events can lead to the Integrated File System Scan on Close exit point being traversed multiple times, causing redundant processing by the ISV solution. - Due to the nature of the scan exit points, stream files will exist in clear-text for a short time before they are encrypted. This is incompatible with security regimes that require sensitive files to be encrypted throughout their entire lifecycle, such as PCI-DSS. - Even if only part of a stream file has changed, the ISV solution always has to re-encrypt the entire stream file, causing unnecessary overhead.
To improve security for data in the IFS i, improve PCI-DSS compliance, and reduce processing overhead, we request the addition of OS support for the transparent encryption/decryption of stream files. This support should satisfy the following requirements:
1) It should be possible to determine on a per-stream-file level or at least a per-IFS-directory level whether the ISV encryption solution will be called when the file is accessed. 2) The ISV encryption/decryption solution must be called automatically when a stream file is accessed, comparable to field procedures or exit points. 3) The ISV solution can return either of the following to the OS via a defined interface: a) the encrypted/decrypted data, or b) an error code to indicate the access is denied. 4) The access logic, i.e. which accesses are allowed and result in the file being decrypted and which are not, is implemented by the ISV solution. 5) Transparent implementation / minimal impact on existing applications. Assuming that the access is allowed by the ISV encryption solution, encryption/decryption would be completely transparent to applications. 6) If only a part of a file is changed, only that part has to be re-encrypted by the ISV solution. E.g., when changes are made to the file, only the modified storage pages would need to be re-encrypted.
Company Acme Inc. stores and exchanges, via NetServer, sensitive files in IFS directory /M3/exchange. The files contain sensitive data. Acme, Inc., wants to protect those files from accidental or malicious snooping, including from *ALLOBJ user profiles.
Encryption would be used to transparently and automatically encrypt the contents of all files in that directory when written. When a job attempts to read the file, the encryption software will determine if the user is on an access list and if yes, decrypt the file contents on the fly for that request, but leave the file encrypted on the disk. Users that are not on the access list just get an error message.
Do not place IBM confidential, company confidential, or personal information into any field.