Service A provides a data access capability that can be used by a variety of service consumers. The database records accessed by Service A are classified as either private or public. There are two types of service consumers that use Service A:

Service consumers with public access permissions (allowed to access only public data records) and service consumers with private access permissions (allowed to access all data records). For performance reasons the Service A architecture uses a single database, named Database A .Each record in Database A is classified as either private or public. After Service A is invoked by a service consumer (1), it authenticates the request message using an identity store and retrieves the corresponding authorization (2, 3). Once authorized, the service consumer's request is submitted to Database A (4), which then returns the requested data (5) If the service consumer has private access permissions, all of the returned data is included in Service A's response message (6). If the service consumer has public access permissions, then Service A first filters the data in order to remove all unauthorized private data records, before sending to the response message to the service consumer (6). An investigation recently detected that private data has been leaked to unauthorized service consumers. An audit of the Service A architecture revealed that Service A's filtering logic is flawed, resulting in situations where private data was accidentally shared with service consumers that only have public access permissions. Further, it was discovered that attackers have been monitoring response messages sent by Service A in order to capture private data. It is subsequently decided to split Database A into two databases:

one containing only private data (the Private Database) and the other containing only public data (the Public Database). What additional changes are necessary to address these security problems?