20
Views
2
Comments
Securing a High-Sensitivity OutSystems App
Application Type
Reactive
Service Studio Version
11.55.28 (Build 64236)
Platform Version
11.33.0 (Build 44426)

Hi everyone,

We’re starting a new application in OutSystems that will handle highly sensitive customer data, and we’ve received a requirement to maximize the security and restrict access at multiple levels. I’d love to hear your thoughts and advice on how to best implement these constraints using OutSystems capabilities and best practices.

🛡️ What we need:

We want to ensure the following:

  1. Only a very limited group of end-users can access the application.

  2. Only a very limited group of developers can access the application modules and the data.

  3. Only a very limited group of platform admins can access this application and its data from within the platform tools (e.g., Service Center, Lifetime).

✅ What we plan to do so far:

  • Restrict app access via roles.

  • Use field-level masking based on roles: for example, users without a special role will see masked values like **** instead of actual sensitive data.

❓Where I need help:

1. Encrypting Data at Rest (Database Level)

We want the data to be encrypted so that even if someone runs queries directly (e.g., via SQL Sandbox or external access), they will not be able to read it. Question: What’s the best approach to encrypt specific fields (e.g., SSN, Tax ID, etc.) in OutSystems? Any recommendations on components, libraries, or patterns to apply encryption/decryption transparently?

2. Restricting Developer Access (Lifetime & Service Center)

All developers in our small team currently have Admin rights in Lifetime, but only a subset of them should be allowed to view/edit this new app and its data. Question: Is there any way to limit visibility or access to this specific application in Lifetime or Service Center without revoking the overall Administrator role from the rest of the team?

Any insights, recommended patterns, or creative workarounds would be greatly appreciated. Thanks in advance!

2023-08-18 10-40-36
Deepak M

1. Encrypting Data at Rest:

  1. Use a Forge component like CryptoAPI or Advanced Encryption Plugin to encrypt/decrypt specific fields (e.g., SSN, Tax ID) at the application level.
  2. For additional security, enable Transparent Data Encryption (TDE) at the database level if you're using Azure SQL or AWS RDS.
  3. Handle encryption/decryption centrally in a core module to maintain consistency.


2. Restricting Developer/Admin Access:

  1. OutSystems doesn’t support per-app access restrictions in Lifetime or Service Center.
  2. Limit Admin roles only to necessary users.
  3. Use a separate environment for sensitive apps where only select developers have access.
  4. Follow strict deployment governance and consider audit logs to track access.
2022-12-01 23-45-12
José Gandarez

Hi Jesus,

Seems the requirement is to encrypt as much as possible because there's highly sensitive customer data. The plan so far seems good enough. 

  1. Don't forget the tradeoff of encrypting almost all data. 
    Example: if you have a list of customers to display, decrypting all those values will increase the load. I recommend selecting only the really sensitive data of the customer on the database as you mentioned.
  2. Use field-level masking based on roles: this masking most be done on the server side level. Because if it's on the client side, the user can "hack" and change the logic to retrieve that information. You were probably already thinking about doing that. 

For the help section, I agree with Deepak.

  1. I would use Crypto API (symmetric encryption algorithm (e.g., AES)) to encrypt and decrypt those values at the server side actions, and saving those on the database level. 
  2. No, you would need to create new "roles". Admin only for really Admin users. Then you can create separated roles to restrict each team to access only the necessary subset of applications.

Summary

  1. End-User: AccessRoles + masking + conditional UI logic
  2. Encrypt Data at Rest: CryptoAPI or external encryption, encrypt before save, decrypt on access
  3. Restrict Developer Access: Isolate sensitive modules; use custom roles; consider infra separationRestrict Lifetime/Service CenterRemove full admin roles; use permission scoping or split environments
  4. Restrict Lifetime/Service Center: Remove full admin roles; use permission scoping or split environments 


I hope this helps :) 

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.