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()

NGO Security References

Old, Deprecated Approach

Old, deprecated approach is based on PHPGACL:

New action wise security draft


Navigation
QR Code
QR Code dev:security (generated for current page)