Added main docs as structure

docs/Artifacts.md

@@ -0,0 +1,41 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	**Artifacts**
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Artifacts
+
+Artifacts repository contains all the components a partner will want to deploy. Each artifact type has its own directory. Ex: All the policies will go in the policy-definition folder. For templates, there are 4 deployments scopes: rg, subscription, MG and tenant. 
+
+For instance, if an ARM template needs to be deployed at tenant level, it will be added in templates/ tenant folder. 
+
+
+    |-- artifacts 
+        |-- dashboards 
+        |-- dsc 
+        |-- pipelines 
+        |-- policy-definitions 
+        |-- role-definitions 
+        |-- scripts 
+        |-- templates 
+            |-- resourcegroup 
+            |-- subscription 
+            |-- managementgroup 
+            |-- tenant 
+        |-- workbooks 
+
+ 
+
+An action will be triggered on any commit in artifacts master repo and all artifacts will be added to the storage account used. Once the resources will be stored in the storage account, any combination of those resources can be deployed to any customer. 

docs/CSP-and-Azure-AD-Tenants.md

@@ -0,0 +1,101 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	**CSP and Azure AD Tenants**
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Buying Azure - Enrollments and Azure AD Tenants
+
+There are multiple ways of purchasing Azure. As a customer you can buy Azure subscriptions through a direct agreement with Microsoft (MCA/Enterprise agrement), on a credit card or buy directly from partners. When purchasing from a partner - there are two different ways you should be aware of - which will have some implications in billing and support. 
+
+[![CSP Models](./media/direct-indirect.JPG)](#)
+
+Figure 1 – CSP Models
+
+CSP Direct model (1-tier)
+-   Partner works with Microsoft directly 
+-   Fixed discount for Azure
+-   Partner needs to provide billing tools and build support practice
+-   Credit check during the onboarding process
+
+CSP Indirect model (2-tier)
+-   CSP Indirect Provider (aka Distributor) – transacts to Microsoft, provides billing tools and technical support.
+-   CSP Indirect Reseller – sells Azure to customers through CSP Indirect Provider.
+
+
+
+## 1. Planning for Enrollment 
+A customer have multiple ways of purchasing Azure. If they chose to transact directly from Microsoft - this is often done through an MCA agremeents. Customers can buy Azure and managed services from multiple partners and CSP is a common way for partners to provide support and managed solutions into the customers environment.
+
+A CSP (Cloud Solution Provider) contract represents the commercial relationship between Microsoft, the partner and the customer regarding their use of Azure. It provides the basis for billing across all customer subscriptions and therefore has an impact on administration of the customer estate. A partner will create a tenant with Microsoft or will create subscriptions on an existing tenant. Each subscription will be billed seperately to the partner who will then be able to bill the customer. For more information on CSP please go here: http://aka.ms/csp
+
+***Design Considerations***
+
+-   The tenant provides a hierarchical organizational structure to govern the management of customer subscriptions.
+
+-   Different customer environments can be separated by using multiple subscriptions on a single tenant to support holistic isolation.
+
+-   There can be multiple administrators appointed to a single tenant and or subscription
+
+-   Each Subscription must have an associated Account owner.
+
+-   Each tenant owner will be made a subscription owner for any subscriptions provisioned under that account. (???)
+
+-   A Subscription can only belong to one tenant at any given time.
+
+-   A Subscription can be suspended based on a specified set of criteria.
+
+***Design Recommendations***
+
+-   Setup the notification account email address to ensure notifications are sent to an appropriate group mailbox.
+
+-   Assign a budget for each subscription and establish an alert associated with the budget.
+
+-   Leverage the Department organisational element to map customer business divisions. (EA Only?)
+
+-   Create a new Department if business domains have independent IT capabilities. (EA Only?)
+
+-   Restrict and minimise the number of owners within the tenant to avoid the proliferation of admin access to subscriptions and associated Azure resources.
+
+-   Separate Dev/Test/Prod environments at an subscription level to support holistic isolation.
+
+<!-- -->
+
+-   Do not ignore notification emails sent to the notification account email address. Microsoft sends important communications to this account.
+
+-   Do not move or rename an owner account in Azure AD.
+
+## 2. Define Azure AD Tenants
+
+An Azure AD tenant is an instance of Azure Active Directory which contains accounts and groups, and acts as an authentication source for subscriptions, which must be rooted to a single AAD tenant.
+
+***Design Considerations***
+
+-   A single tenant can have multiple CSP Azure subscriptions.
+
+***Design Recommendations***
+
+-   Leverage AAD SSO based on the selected [planning topology](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies).
+
+-   Enforce MFA and conditional access policies for all privileged accounts.
+
+-   Plan for Emergency access or break-glass accounts to prevent tenant-wide account lockout.
+
+-   Use AAD PIM for Identity and Access management.
+
+-   If Dev/Test/Prod are going to be completely isolated environments from an identity perspective, separate them at a subscription level.
+
+<!-- -->
+
+-   Avoid creating a new AAD tenant unless there is a strong IAM justification and processes are already in-place.

docs/Design-Guidelines.md

@@ -0,0 +1,18 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* **Design Guidelines**
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Design Guidelines

docs/Identity-Access-Management-and-Lighthouse.md

@@ -0,0 +1,160 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    - [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	**Identity, Access Management and Lighthouse**
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Identity, Access Management and Lighthouse
+[![Identity and Access Management](./media/iam.png "Identity and Access Management")](#)
+
+Figure 4 – Identity and Access Management
+
+**Identity Baseline** is one of the Five Disciplines of Cloud Governance within the Cloud Adoption Framework governance model. Identity is increasingly considered the primary security perimeter in the cloud, which is a shift from the traditional focus on network security. Identity services provide the core mechanisms supporting access control and organization within IT environments, and the Identity Baseline discipline complements the Security Baseline discipline by consistently applying authentication and authorization requirements across cloud adoption efforts.
+
+This section will examine design considerations and recommendations surrounding identity and access management for Microsoft partners.
+
+## 1. Planning for Authentication Management
+
+A key factor in for a cloud CSP in structuring the cloud-based identity services is the level of integration required with your existing on-premises identity infrastructure. Requirements for authentication inside the "Landing Zone" should therefore be thoroughly assessed and incorporated into plans to deploy AD, AAD-DS or both.
+
+***Design Considerations***
+
+-   Centralized and delegated responsibilities to manage resources deployed inside the "Landing Zone".
+-   Capability and performance differences between AD, AAD, and AAD Domain Services.
+-   There are some Azure services that rely on AAD-DS, such as HDInsight, Azure File Service, WVD.
+-   Handling of privileged operations, such as creating a Service Principal within the AAD tenant, Registering Graph applications inside AAD, and procuring a wildcard certificate.
+-   AAD Proxy frontend authentication for applications relying on Integrated Windows Authentication (IWA), Forms/Header based authentication as well as rich client apps integrated with ADAL.
+
+***Design Recommendations***
+
+- Cloud-based identity management is an iterative process. You should choose the model that is matching your cloud maturity level. One can always start small with a small set of users in a cloud native solution.
+
+- Come up with relevant cloud policy statements to address specific risks identified in the risk assessment cycle. For each statement, identify the following information: **technical risk**, **policy statement**, and **design options**. Some example risks: weak authentication mechanisms, lack of shared management accounts between on premises and the cloud, isolated identity providers, etc. 
+
+  Expanding one topic as example:
+
+  ######       Weak authentication mechanisms
+
+  ​      **-  Technical risk:** Identity management systems with insufficiently secure user authentication methods, such as basic user/password combinations, can lead to compromised or hacked passwords, providing a major risk of unauthorized access to secure cloud systems.
+
+  ​      **- Policy statement:** All accounts are required to sign in to secured resources using a multi-factor authentication method.
+
+  ​      **- Potential design options:** For Azure Active Directory, implement Azure MFA as part of your user authorization process.
+
+- Evaluate the toolchain options and implement your toolchain by first rolling out in a pre-deployment phase, and then migrate.
+
+- Develop a (draft) Architecture Guideline document. First review for that purpose the use of patterns discussed throughout the architectural decision guides.
+
+- Customize the toolchain based on changes in your organization’s requirements and needs. Update the Architecture Guideline document accordingly.
+
+- Evaluate the compatibility of workloads for AD and AAD-DS.
+
+-   Deploy AAD-DS within the primary region as this service can be projected into only one subscription.
+
+    -   Use Virtual Network Peering to support its usage as an authentication service.
+
+- Use Managed Identities instead of Service Principles for authentication to Azure services.
+
+-   Use Just-In-Time access for both VM access and Azure control plane administration.
+
+-   Do not assume existing workloads are agnostic of AD and AAD-DS authentication, as there are differences between both approaches.
+## 2. Planning for Access Management
+
+CSPs will typically follow a least-privileged approach to operational access and this model should be expanded to consider Azure through AAD RBAC and custom role definitions. It is therefore critical to appropriately plan how to govern control plane and data plane access to resources in Azure, while also fully aligning with Joiner/Mover/Leaver (JML) processes.
+
+***Design Considerations***
+
+- There is a limit of 2000 custom RBAC role assignments per subscription.
+
+- There is a limit of 500 custom RBAC role assignments per management group.
+
+-   Centralized versus federated resource ownership.
+
+    -   Shared resources such as the network will need managed centrally.
+
+    -   The management of application resources can be delegated to application teams.
+    
+- Custom role definitions can be used to map responsibility boundaries between central and application teams.
+
+- Azure AD resides in an Azure subscription. Global Admin can self-designate permission to manage Azure. Service & Account Admins are assigned on each subscription.
+
+- Challenges of AOBO (admin on behalf of): 
+
+  - No granularity between customers. Users in Admin Agents Group get Owner permissions in all Azure subscriptions of  all .customers
+  - No granularity on Azure. Users in Admin Agents Group are owners and role cannot be changed.
+
+- Challenges for MSPs in Azure include such as inconsistent identity management (B2B invites, CSP admin agents, foreign principle), no cross-tenant visibility as well as complexity in managing customers at scale. The recommended solution is to use Azure lighthouse (elaborated more in the recommendations).
+
+  
+
+***Design Recommendations***
+
+-   Use AAD RBAC to manage data plane access to resources where possible (e.g. Key Vault, Storage Account, Azure SQL DB).
+-   Use AAD PIM to establish zero standing access.
+-   Use "AAD only" groups for Azure control plane resources in PIM when creating entitlements.
+
+    -   Add on-premise groups to the "AAD only" group if there is an existing group management system already in place.
+-   Integrate Azure AD logs with Azure Log Analytics.
+-   To simplify permissions, evaluate and choose from the built in roles designed to cover most normal scenarios and avoid creating complicated custom roles. 
+-   Avoid Granular and custom permissions specifically referencing resources or users. 
+    -   Use *management group* and *resource group* rather than resource specific permissions.
+    -   To *assign access to groups in Azure AD* rather than using user specific permissions.
+-   Use Identity Score in Azure Active Directory to identify key recommendations and monitor progress.
+-   Govern all the employees, vendors, and contractors that take on administrative rights need by leveraging the “Just-In-Time” and “Just-Enough” admin capabilities of AAD PIM.
+-   Set up a process to manage access beyond what was initially provisioned for a user when that user’s identity was created. Consider automating the process through technologies such as dynamic groups and entitlements.
+-   Set up recurring review pattern and regularly review privileges with a business-critical impact.
+-   Use terms of use to get formal consent from users in form of accepting your terms of use (ToU)
+-   Use Custom RBAC role definitions within the AAD tenant, considering the following key roles
+
+| Role                             | Usage                                                        | Actions:                                                     | No Actions:                                                  |
+| -------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| Azure Platform Owner             | Management Group and Subscription lifecycle management       | *                                                            |                                                              |
+| Network Management (NetOps)      | Platform wide Global Connectivity management; VNets, UDRs, NSGs, NVAs, VPN, ER etc. | \*/read, Microsoft.Authorization/\*/write, Microsoft.Network/vpnGateways/\*, Microsoft.Network/expressRouteCircuits/\*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnsites/\* |                                                              |
+| Security Operations (SecOps)     | Security Administrator role with a horizontal view across the entire Azure estate and the KV Purge Policy | \*/read, \*/register/action, Microsoft.KeyVault/locations/deletedVaults/purge/action, <br> Microsoft.Insights/alertRules/\*, Microsoft.Authorization/policyDefinitions/\*, Microsoft.Authorization/policyassignments/\*, Microsoft.Authorization/policysetdefinitions/\*, Microsoft.PolicyInsights/\*,Microsoft.Security/\* |                                                              |
+| Subscription Owner               | Delegated Role for Subscription Owner derived from subscription Owner role | *                                                            | Microsoft.Authorization/\*/write, Microsoft.Network/vpnGateways/\*, Microsoft.Network/expressRouteCircuits/\*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnsites/\* |
+| Application Owners DevOps/AppOps | Contributor role granted for application/operations team at resource group level |                                                              | Microsoft.Network/publicIPAddresses/write, Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action |
+
+-   Use JIT for all IaaS Resources to enable network level protection.
+
+-   Use AAD Managed Service Identities (MSI) for Azure resources, avoiding username and password-based authentication.
+
+-   Use privileged identities for automation runbooks that require elevated access permissions.
+
+<!-- -->
+
+- Do not add users directly to Azure resource scopes.
+
+- Adopt **Azure Lighthouse** , which offers service providers a single control plane to view and manage Azure across all their customers with higher automation, scale, and enhanced governance:
+
+  - it allows finer control on what permission each user/group gets
+  - shall reduce the number of users with the Admin Agents role
+  - Enable all advanced security features for those users (MFA, IP, PIM)
+
+- Some best security practices:
+
+  - Enable MFA on MSP tenant
+
+  - Apply principle of least privilege
+
+  - Use AAD PIM to control access to delegated groups (in private preview)
+
+  - Additional segmentation can be achieved creating groups per customer or industry segment
+
+    - Example:
+
+      1. Tier 1 support group assigned to every customer as Reader
+
+      2. Tier 2 and 3 support are assigned on a customer by customer basis
+
+         --> This would mean creating one marketplace offer plan or template per industry or per customer

docs/Landing-zones.md

@@ -0,0 +1,18 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* **Landing zones**
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Landing zones

docs/Management-Group-and-Subscription-Organisation.md

@@ -0,0 +1,81 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	**Management Group and Subscription Organisation**
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Management Group and Subscription Organisation
+[![Management Group Hierarchy](./media/mg.png "Management Group Hierarchy")](#)
+
+Figure 1 – Management Group Hierarchy
+
+
+Within an AAD tenant, Management Group structures help to support organisational mapping and must therefore be appropriately considered when planning Azure adoption at-scale.
+
+***Design Considerations***
+
+-   Subscriptions serve as a scale unit so that component workloads can scale within platform [subscription limits](https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits).
+
+-   Management groups can be used to aggregate Policy and Initiative assignments.
+
+-   There is a limit of 7 levels in any nested Management Group structure.
+
+-   Management groups and subscriptions can only support one parent
+
+-   Management groups can have many children
+
+-   Same subscription can't be part of multiple MGs. You can move subscriptions between MGs.
+
+-   Certain role will be needed to create MGs. Check [Management Group Access](https://docs.microsoft.com/en-us/azure/governance/management-groups/overview#management-group-access)
+ 
+
+***Design Recommendations***
+
+-   Treat subscriptions as a democratised unit of management aligned with business needs and priorities
+
+-   Decide which resource types are available in a subscription by default.
+
+-   Decide what all standard subscriptions should look like. Considerations include RBAC access, policies, tags, and infrastructure resources.
+
+-   Define structures for naming and tagging
+
+-   Segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, allow only certain actions at a particular scope. 
+
+-   Prefered to programmatically create new subscriptions via a service principal. You must grant permission to the service principal to create subscriptions.
+
+-   Use management groups to model your organization or mirror your billing hierarchy
+
+-   Group Subscriptions in MG based on a need for common roles assigned along with Azure Policies and initiatives
+
+-   Do not create Subscriptions under the "root" Management Group.
+
+-   Do not transpose the organisational structure into a deeply nested management group hierarchy.
+
+-   Limit the number of Azure Policy assignments made at the root Management Group scope to avoid managing through exclusions at inherited scopes.
+
+
+***Example***
+
+[![Production and nonproduction subscriptions](./media/dev-prod.png "Production and nonproduction subscriptions")](#)
+
+Figure 2 – Production and nonproduction subscriptions
+
+-   Using separate subscriptions for your production and nonproduction environments creates a boundary that makes management of your resources simpler and safer.
+-   Azure has specific Dev/Test subscription offerings for nonproduction workloads. These offerings provide discounted rates on Azure services and software licensing.
+-   Your production and nonproduction environments will likely have different sets of Azure policies. -   Using separate subscriptions makes it simple to apply each distinct policy at the subscription level.
+-   You can allow certain types of Azure resources in your nonproduction subscription for testing purposes. You can enable those resource providers in your nonproduction subscription without making them available in your production environment.
+-   You can use dev/test subscriptions as isolated sandbox environments. These sandboxes allow administrators and developers to rapidly build up and tear down entire sets of Azure resources. This isolation can also help with data protection and security concerns.
+-   The acceptable cost thresholds that you define will likely vary between production and dev/test subscriptions.
+
+

docs/Management-and-Monitoring.md

@@ -0,0 +1,93 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	**Management and Monitoring**
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Management and Monitoring
+[![Monitoring on Azure](./media/monitor.png "Monitoring on Azure")](#)
+
+Figure 1 – Monitoring on Azure
+
+***Design Considerations***
+
+-   Understand what should be monitored & who needs to be notified
+
+-   Understand out-of-the-box & on-by-default data collection already available for Azure Resources
+
+-   Ensure appropriate levels of data access using RBAC. Monitoring Reader or Monitoring Contributor roles can grant access to monitoring data while restricting broader access. Central teams can access all logs with Workspace Access, while individual teams might just be given Resource Access
+
+-   Decide whether to use separate or single Application Insights Resource for your scenarior
+    -   Separate resources can help save costs, prevent data mix-up and allow more relaxed access
+    -   Single resource can help keep all relevant telemetry in the same place to use with Application Insights features
+        -   Different independent applications -> Use separate iKeys for each app
+        -   Multiple microservices or roles of one business application -> Use a single iKey; Filter/Segment telemetry by cloud_RoleName property
+        -   Dev, Test & Production -> Use separate iKeys for each stage/environment of release
+        -   A | B Testing -> Use a single iKey; Add custom property to identify variants
+
+-   Prefer Metric Alerts for better performance/latency; Use Log Alerts for powerful query-based triggers or lack of metrics
+
+-   Consider collecting and integrating additional AKS workload metrics from Prometheus
+
+-   Consider custom telemetry to gain valuable logs, distributed tracing & usage insights
+
+-   Setup actionable alerts with notifications and/or remediation
+
+-   Properly define severity/descriptions and avoid sending blanket notifications to people who cannot take any actions
+
+-   Optimize Cost - Collect & Retain only as much data as you need 
+    -   Review configuration settings to reduce frequency of data collection and only collect required logs (e.g. avoid Info)
+    -   Setup appropriate data caps to avoid anomalous spikes / bill shocks and configure data cap alerts to avoid losing data
+    -   Use sampling to reduce number of telemetry items that are actually sent from your apps
+    -   Setting lower retention on selected data types can be used to reduce your data costs
+    -   Leverage reserved capacity pricing when appropriate for lower costs
+    -   Evaluate recommendations from Azure Advisor to help optimize Availability, Security, Performance & Cost
+
+-   Ways to reduce Logs Data Collection
+    -   Select [common or minimal security events](https://docs.microsoft.com/azure/security-center/security-center-enable-data-collection#data-collection-tier). Change the security audit policy to collect only needed events. Review the need to collect events for: audit filtering platform, audit registry, audit file system, audit kernel object, audit handle manipulation, audit removable storage
+    -   Change [performance counter configuration](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-sources-performance-counters) to reduce the frequency of collection and the number of performance counters
+    -   Change [event log configuration](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-sources-windows-events) to reduce the number of event logs collected. Collect only required event levels. E.g. do not collect Information level events
+    -   Change [syslog configuration](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-sources-syslog) to reduce the number of facilities collected. Collect only required event levels. E.g. do not collect Info and Debug level events
+    -   Change resource log collection to reduce the number of resources send logs to Log Analytics. Collect only required logs
+
+***Design Recommendations***
+
+-   Configure Agents & Diagnostic Settings for additional logs/perf counters as needed 
+    -   Install Log Analytics Agent to collect data from Guest OS & VM Workloads in LA workspaces. Required for writing Log Analytics Queries or using VM Insights, Azure Security Center or Azure Sentinel.  
+    -   Configure Diagnostics Settings in resource-specific mode, which makes it easy to discover schemas and write queries
+    -   Use Dependency Agent to collect discovered data about running processes & external process dependencies on VMs. Required for VM Insights Maps feature and has dependency on Log Analytics Agent.
+
+-   Log Analytics workspace setup: use as few as possible, unless there are specific organizational requirements or geographical data sovereignty constraints
+
+-   Automate agent deployment, insights enablement & diagnostics settings configuration across resources via:
+    -   Azure Automation DSC (Desired State Configuration)
+    -   Azure CLI / PowerShell
+    -   Azure Resource Manager (ARM) Templates
+    -   Azure Policy
+
+-   Integrate with Release Management via Azure DevOps Pipelines/Github actions
+
+-   Connect Alerts with ITSM or Ticketing Systems (like Service Now or Pager Duty) for efficient management
+
+-   Setup Automation Runbooks and/or Custom Workflows (Logic Apps) for Auto-Healing & Remediations 
+
+-   Use Action Rules to manage Alert Suppression & Actions at scale
+
+-   Create Scheduled Queries via Logic Apps to run custom alerts on schedule
+
+-   Auto-Scaling can be performed on a schedule, or based on a runtime metric, such as CPU or memory usage
+
+- Enable Smart Detection Alerts
+    -   Application Insights Smart Detection: Out-of-the-box Alert Rules which help detect anomalies like slow page load time, slow server response time, degradation in server response time, degradation in dependency duration, abnormal rise in exception volume, potential memory leak, potential security issue, etc.	
+    -   Dynamic Threshold Metric Alerts: Detect patterns in the data such as seasonality (Hourly/Daily/Weekly). Sensitivity can be set to control amount of deviation from behavior required to trigger an alert (Medium/Low helps reduce Alert Noise). 

docs/Multi-tenant-deployments.md

@@ -0,0 +1,17 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	**Multi tenant deployments**
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Multi tenant deployments

docs/Platform-Automation-and-DevOps.md

@@ -0,0 +1,19 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	[Security, Governance and Compliance](./Security-Governance-and-Compliance.md)
+    -	**Platform Automation and DevOps**
+---
+
+
+# Working document
+[Open working document](https://microsofteur-my.sharepoint.com/:w:/g/personal/hafianba_microsoft_com/EdSBgTlOEk5LnhXsIfwAmTEB4itZU3wvpXhpSF1BVy7I3w?e=IgOu8P)

docs/Security-Governance-and-Compliance.md

@@ -0,0 +1,56 @@
+## Navigation Menu
+* [Getting started](../src/platform-automation#platform-automation---getting-started)
+* [Landing zones](./Landing-zones.md)
+    -	[Artifacts](./Artifacts.md)
+    -   [Customers](../src/platform-automation/cmdb#customers)
+    -	[Multi tenant deployments](./Multi-tenant-deployments.md)
+* [Platform automation at scale](./Platform-automation-at-scale.md)
+* [Design Guidelines](./Design-Guidelines.md)
+    -	[CSP and Azure AD Tenants](./CSP-and-Azure-AD-Tenants.md)
+    -	[Identity, Access Management and Lighthouse](./Identity-Access-Management-and-Lighthouse.md)
+    -	[Management Group and Subscription Organisation](./Management-Group-and-Subscription-Organisation.md)
+    -	[Management and Monitoring](./Management-and-Monitoring.md)
+    -	**Security, Governance and Compliance**
+    -	[Platform Automation and DevOps](./Platform-Automation-and-DevOps.md)
+---
+
+
+# Security, Governance and Compliance
+
+## 1. Data Protection
+
+- Create policies that enforce the use of encryption at rest on VMs and App Services when available. 
+
+- When possible, use Microsoft managed encryption keys. This saves time and resources on key management activities.
+
+- If customer requires to manage its own keys, use Azure KeyVault when possible. Use one KeyVault per security boundary.
+
+- See more details about encryption design choices [here](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/encryption/) and [here](https://docs.microsoft.com/en-us/azure/security/fundamentals/data-encryption-best-practices). 
+
+- See Azure Encryption options in the image below
+
+[![Azure Encryotion Options](./media/azure-encryption-options.PNG)](#)
+
+## 2. Security Management
+
+- Enable Azure Security Center (ASC) for all customer subscriptions. 
+
+- Create your own customized policies for Azure Security Center that match your own recommendations. You might have several custom policies to adjust to different customer segments (ie. financial vs public sector) or to different managed services you offer (ie. full security posture management service vs managed detection and response).
+
+- Keep every custom policy that you create as code in your repository, to enhance traceability and automation.
+
+- Monitor Secure Score and act upon recommendations. Create your own workflows to automate the response to recommendations (ie. enable Just In Time access for VMs). More details [here](https://docs.microsoft.com/en-us/azure/security-center/workflow-automation).
+
+- Stream ASC recommendations to your log analytics workspace so you can build dashboards and workbooks based on this data. More details [here](https://docs.microsoft.com/en-us/azure/security-center/continuous-export).
+
+
+## 3. Threat Protection
+
+- When possible enable ASC Standard Tier to add Threat protection capabilities for VMs and PaaS services. Remember that Standard Tier includes Microsoft Defender ATP for Windows Servers.
+
+- Create your own automated response to attacks coming from ASC. More details [here](https://docs.microsoft.com/en-us/azure/security-center/workflow-automation).
+
+- If using Azure Sentinel, connect ASC to it to receive all relevant alerts. If using a different SIEM, configure Continuous Export to send relevant data to Event Hub and then to external SIEM. More details [here](https://docs.microsoft.com/en-us/azure/security-center/continuous-export).
+
+- If using Azure Sentinel as your customer's SIEM, watch [this webinar](https://youtu.be/hwahlwgJPnE) focused on MSSP best practices with all the considerations to take into account.
+