Table of Contents
Data Security and Privacy Design
Introduction
In Sahana, we have decided to stick to KISS principles on security design as over complicated security frameworks also can yield numerous flaws due to the human error. Thus the understandability of the security mechanism is also key to maintaining security.
With regard to this we have come up with the following:
Authorization and Data Sensitivity
Authorization in Sahana is handled through pre-defined data classification levels and well known user roles in disasters.
Data Classification
- Person Sensitive - Data that can cause harm to the person in the wrong hands
- Organization Sensitive - Data that can cause an participating organization harm
- Legally Sensitive - Data that is bound legally to sharing
- National Security Sensitive - Data that if in the wrong hands can be a threat to National Security
- Socially Sensitive - Data that is sensitive to the society affected in the disaster
- Disaster Mitigation Sensitive - Information that might cause problems in mitigation disasters especially when released to the public
- System Sensitive - Data that can be used to crack or break into the system
- Not Sensitive - Data not known to be sensitive
- Unclassified - Unknown or undefined sensitivity of data
User Roles
- Administrator (Admin) - The system admin / root user
- Main Operations Coordinator (MainOps) - The officially designated relief coordinator
- Head Organization Contact (OrgHead) - The senior most user for a trusted participating organization (NGO, Gov Ministry, etc)
- Trusted User (Trusted) - An officially trusted and designated user of the system. Often member of a trusted supporting organization.
- Registered User - A registered user in the system (e.g Volunteers, Family)
- Anonymous User - An unauthenticated user
Default Data Classification to Role Mapping
The following gives the default Mapping, which can be altered by the system admin based on the requirements during deployment.
| Data Classification | Roles that have access |
|---|---|
| Person Sensitive | MainOps, OrgHead, Trusted |
| Organization Sensitive | MainOps, OrgHead |
| Legally Sensitive | MainOps, OrgHead, Trusted |
| National Security Sensitive | MainOps |
| Socially Sensitive | MainOps, OrgHead, Trusted |
| System Sensitive | Admin |
| Not Sensitive | All |
| Unclassified | MainOps, OrgHead, Trusted |
Implementation
Implemented in version 0.6
Minimal requirement to implement ACL in a new module is to include a proper sec_policy.xml. If it also requires new tables, data classification levels or roles, then they need to add them to “mysql-config.sql”. e.g.:
INSERT INTO sys_data_classifications VALUES ( 4, 'National Security Sensitive'); INSERT INTO sys_user_groups VALUES ( 2, 'Registered User');
The necessary headers (lib_acl.inc, lib_auth.inc) are already included via the front controller, so don't need including again.
These functions used to check ACL should be left to the framework & not used directly by modules:
shn_acl_get_state() shn_acl_check_perms_action()
- VM ACL (proposed) which includes a useful description of the main Sahana ACL
NGO Security References
Old, Deprecated Approach
Old, deprecated approach is based on PHPGACL:
