Security View

Security is an important aspect of most systems, so it’s essential that it is thought about and documented clearly. Having a dedicated security section provides a way to explain how your architecture will meet security requirements such as authentication, authorisation, data confidentiality, etc. Some organisations have specialised security teams that will help with and/or need to review your work in this area before deploying your system into a production environment. Being explicit about security helps you spot any holes before it’s too late.

Is there a clear understanding of how security is handled within the architecture and how have any security requirements have been satisfied? This may cover:

• Authentication.
• Authorisation.
• Confidentiality of data between components (e.g. during user login, during requests between components, using technologies such as web services or messaging, across public networks).
• Non-repudiation.
• Different types of users and their roles.
• The use of a security realm or integration with in-house single sign-on mechanisms.
• Network separation using firewalls and DMZs (red, amber, green model).
• Restricted access to resources.
• Permissioning of data of a per user/role/etc basis and the ability to modify those permissions.
• Storage of credentials (e.g. database logons).
• Distribution of certificates and keys.
• Runtime sandbox.
• Signed binaries.
• Essential code only on each architectural tier.