From 3d138b892afa927855e5588316cfcfbe73ee1ce3 Mon Sep 17 00:00:00 2001 From: Daniel Sevostyanov <12199206+SevDan@users.noreply.github.com> Date: Wed, 17 Mar 2021 21:55:27 +0400 Subject: [PATCH] #1 Continued standard n.1 to 5. Repl. & Rel. Infr. --- ...nt-and-operations-01-incomplete-000001.txt | 119 +++++++++++++++++- 1 file changed, 115 insertions(+), 4 deletions(-) diff --git a/common/development/1/mgppqs-1-common-development-and-operations-01-incomplete-000001.txt b/common/development/1/mgppqs-1-common-development-and-operations-01-incomplete-000001.txt index bd3c058..b582811 100644 --- a/common/development/1/mgppqs-1-common-development-and-operations-01-incomplete-000001.txt +++ b/common/development/1/mgppqs-1-common-development-and-operations-01-incomplete-000001.txt @@ -16,6 +16,8 @@ Next recommendations could be useful for all software development & operations t - RDBMS - Relational Database Management System - software product that has a lot of functions to work with databases. - ISMS - Information Security Management System. - SSO - Single Sign-On +- System Business Value Source* - main source of system business value. When it doesn't works, system cannot invoce benefits. +(*maybe some better general term exists, just didn't remember it at writing moment - SevDan) 3. Preconditions @@ -90,13 +92,13 @@ B. Security, Permissions, Access C. Critical Information 1. Payment Processes -2. Grant Permissions +2. Granting Permissions 3. Logs & Alerts Policy 4. Event Sourcing 4.1. Events Driven 4.2. Source of Trurh 4.3. CQRS -5. Replication & Reliable Infrastructures +5. Replication & Reliable Infrastructure D. Common Topics 1. Departments & Intercommunication @@ -571,7 +573,8 @@ Use password (hash-based) or certificate key way. You can save your credentials in configuration files or secrets storage (i.e HashiCorp Vault). Pay attention: you should use SE Linux or some other Linux security access tools to prevent leaks. -Don't use default / simple credentials for database connect. +Don't use default / simple credentials for database 5. Replication & Reliable Infrastructures +connect. 3.2. Schemas @@ -735,7 +738,109 @@ In most cases Roles Model is enought. C. Critical Information --- TODO C -- +There are some points that may be critical for your product. +Typically the critical points contains business mandatory features (that makes system sense, brings the main income). +It named System Business Value Source in this standard. + +You should care about that points at most. +You must keep it secure and safe as strong as you can. + +1. Payment Processes + +The most popular games monetization feature is donate system or game valuables trading. +So, it means you have payment subsystem / integration as critical point. + +There are some requirements for payment feature: +1. You must save payments information in long term storage. +2. You must verify all incoming payments for correct values. +3. You must give write & read access only for all payments subsystems storage users (administrators, managers, services, subsystems etc.) (without edit / delete) +4. You should analyse payment communication formats and create robust architecture & implementation for it. +(you can use XP with TDD, create dedicated reliable QA strategy with different acceptance tests, mutation testing and other advanced techniques for it) +5. You should use trusted payments service provider. But vendor locking is a bad idea. (robust but adaptive tactics may be better) + +2. Granting Permissions + +You should control your granting permissions process. +Permissions granting logs is the most important information for audit & social engineering security. + +So, you can use different granting process types: +1. One Granter - one team member who has granter permissions (i.e. admin) will grant permissions for others. +Good enought for simple situation without sensitive information & access. +2. Automatic Quorum - 2 steps of granting: request by voter & validation by some reviewers. Grant permissions only when enought team members voted for it. +Good for flat team structure. +3. Different Responsibility - split granting for some responsibility: a) grant role b) grant permissions +Good for multilayers team. +4. Full Escalation - only requests that escalates to next level. +Upper level team member validates requests, package it and escalate upward until product owner / director accepts / deny whole package. +Good for sensitive data, but too much overhead. +5. Adaptive Escalation - execute some granting requests immediantly and escalate reports and random/policies-based permissions granting. (i.e. based on frequency) + +You can develop your own way for granting permissions. +Pay attention at: +1. SSO - permissions granting process should place in one place. +2. Audit - permissions granting processes should be available for periodically audit. Some strategies requires it. (like 'One Granter') +3. Logging - permissions granting processes should be reliable logged. +4. Trust & security management - permissions granting processes should be consistent with trust & security management (maybe you should integrate it ISMS). +Security incidents analysis will be based on permissions granting & responsibility tracing information. + +3. Logs & Alerts Policy + +You must have robust & trusted logs and robust & trusted alerts for sensitive and System Business Value Source features. + +Logging & alerting are full of trade-offs. You should track information that will be read by human. +That why tracking depends on business domain & values. +You shouldn't track all modules with same policy. Tracing policies should reflect business values. + +There are many tools & systems for logs analysis and you should be able to use it. (i.e. ELK stack) + +Pay attention at tracing information: +1. You should trace timestamp in correct format. (in one time zone) +2. You should trace incidents in WWW format. (like test case) (Where, What happened, Why there is a mistake) +3. You should trace navigation : service name, server IP, POD ID and other depends on your architecture. +4. You must escape sensitive & personal data (names, emails, keys, tokens etc.) + +4. Event Sourcing + +There are some good architectures for critical, reliable and fault tolerance solutions. +That architectures are good candidate for System Business Value Source modules. + +If you want to get robust business, your product & financial flow should be robust. +But you don't need to make all components equaly reliable. (it can cost too much) + +One of the good architectural pattern is event sourcing. +Event Sourcing means you should save information in events view and save it forever. +So, your system will not execute delete or edit changes in events storage. +To use information from event source, you have to create and update snapshot with events replay. + +4.1. Events Driven + +Events Sourcing are good for Actors systems (like Erlang/OTP, Akka and other). Some of them implements good API for Event Sourcing persisting. +You can use it in other systems too (with well-known RDBMS), you just should implement it by yourself. + +There are Events Driven systems that can be easy integrate with Event Sourcing. (i.e. reactive systems with good interactive for soft real time apps (as games)) + +4.2. Source of Truth + +If you have different databases (event sources and CRUD snapshot) for same data (i.e. one for save data and one for current snapshot), you can have bad problem with desynchronization. +So, you have to choose some database as source of truth. At most cases event sourcing storage are better for it. +If you choose it, you should implement re-plays operations and do it when your system indicates that CRUD database is in inconsistent state. + +Sometimes you cannot use Event Source as source of truth and you have to use current shapshot for it. +So, you can get more difficult synchronization procedures. +For instance, you can implement synchronization daemon process that will create sync events in event sourcing storage every time when it will starts and indicate that snapshot has new state. +But mostly you don't need to do it. You can just use event sourcing for loggin or replays and provide consitency with other techniques. + +4.3. CQRS + +There is a good way to organize your data communication - CQRS. +CQRS means command-query separation. You should separate you reads and writes to implement CQRS. +So, it solves some problems (event sourcing storage will be source of truth) with choosing source of truth and provide you abilities to build reliable & distributed systems. +It has some problems with write & reads reordering: some difficult solutions can has race conditions of it. +So, you should think over all core aspects before implements CQRS. Maybe you cant use it in some cases. + +5. Replication & Reliable Infrastructure + +-- TODO 5. -- -- TODO -- @@ -763,12 +868,18 @@ HashCorp Vault (secrets storage) : vaultproject.io Kerberos protocol : tools.ietf.org/rfc/rfc4120 Bitwarden : github.com/bitwarden bitwarden_rs : github.com/dani-garcia/bitwarden_rs +ELK : elastic.co/what-is/elk-stack +Erlang/OTP : erlang.org/doc +Akka : akka.io Agile Manifesto : agilemanifesto.org Martin Fowler blog : martinfowler.com Joel Spolsky about leaky abstractions : joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions OWASP ASVS standard : github.com/OWASP/ASVS ISMS Online (ISMS Software) : isms.online +Event Sourcing by Martin Fowler : martinfowler.com/eaaDev/EventSourcing.html +CQRS by Martin Fowler : martinfowler.com/bliki/CQRS.html +Reactive Manifesto : reactivemanifesto.org Jesse Schell "The Art of Game Design" : amazon.com/Art-Game-Design-Lenses-Third/dp/1138632058 Martin Fowler "Refactoring" : martinfowler.com/books/refactoring.html