Feedback App Design: Role-Based Access Control with Keys

Designing a Secure Feedback Application

Building a feedback application with granular access control requires careful consideration of how data is stored, retrieved, and presented. The core challenge is ensuring that feedback, once submitted, is only accessible to its intended audience: the recipient and an HR administrator. This means implementing a robust access control mechanism that prevents unauthorized viewing by other users, including support staff, DBAs, or even other recipients of feedback. The key to achieving this lies in how you structure your data and manage access permissions, often through a combination of user roles and carefully managed keys.

Role-Based Access Control (RBAC) Strategy

A fundamental approach to managing access in such an application is Role-Based Access Control (RBAC). In this model, users are assigned roles, and permissions are granted to these roles rather than directly to individual users. For your feedback app, the primary roles would be:

• Recipient: The individual who has received the feedback. They should only see feedback specifically directed at them.
• HR Admin: A super-user role with privileges to view all feedback, manage users, and potentially moderate content.
• Submitter: The person providing the feedback. Their access is typically limited to viewing the feedback they have submitted (if that's a requirement, though your prompt implies they don't see it), but crucially, they should NOT see feedback directed at others.
• Other Users: This category includes anyone else in the system – support staff, DBAs, general employees, etc. They should have no access to any feedback data.

This RBAC model forms the basis of your security. However, simply assigning roles isn't enough; the implementation details, particularly how you use keys, are critical for true security.

Data Modeling and Key Management

The way you model your feedback data and manage associated keys will directly impact the security and scalability of your application. A common and effective pattern involves using unique identifiers and, where necessary, encryption keys.

Feedback Record Structure

Each feedback record should contain at least the following information:

• Feedback ID: A unique identifier for the feedback entry.
• Recipient ID: The ID of the user receiving the feedback.
• Submitter ID: The ID of the user who submitted the feedback.
• Feedback Content: The actual text of the feedback.
• Timestamp: When the feedback was submitted.
• Visibility Status/Flags: (Optional but helpful) Flags indicating general visibility, though primary control will be application-level.

Using Keys for Access Control

The term "keys" can be interpreted in several ways in this context: database primary/foreign keys, API keys, or encryption keys. For robust security, a combination is often best.

1. Database Keys (Primary/Foreign Keys)

Standard database practice dictates using primary keys for unique identification and foreign keys to link related records (e.g., linking feedback to users). These are essential for data integrity and efficient querying. However, they do not inherently provide security. Anyone with direct database access could potentially query all feedback records if not further protected.

2. User and Role Identification

When a user interacts with the application, their authenticated session should provide their User ID and their assigned Role(s). This information is paramount for the application logic to decide what data they are allowed to see.

3. Application-Level Authorization Logic

The application layer is where the actual access control enforcement happens. When a user requests to view feedback:

• For a Recipient: The application checks if the requested Feedback ID's Recipient ID matches the logged-in user's User ID. If they match, the feedback is displayed.
• For an HR Admin: The application checks if the logged-in user has the 'HR Admin' role. If so, they are granted access to view any feedback record, regardless of Recipient ID or Submitter ID.
• For Other Users: Any request that does not meet the criteria for a Recipient or HR Admin is denied.

4. Encryption Keys (for Enhanced Security)

While RBAC and application logic are strong, the ultimate security comes from encrypting sensitive data. For feedback content, consider encrypting it at rest.

• Symmetric Encryption: A single encryption key can be used to encrypt and decrypt the feedback content. This key would need to be securely managed. The HR Admin would need access to this key to decrypt feedback. The recipient's access would be mediated by the application, which uses the key to decrypt the feedback for them.
• Key Management System (KMS): Instead of managing keys directly in application code, use a dedicated KMS. This system can store, rotate, and manage access to encryption keys. The application would request decryption from the KMS, proving its identity and authorization (e.g., via service accounts or API keys).

The surprising detail here is that even with robust RBAC, true data privacy at rest often necessitates encryption. Without it, a compromised database or a malicious DBA could still expose sensitive feedback, even if the application logic prevents it.