root

Structure

Domain – Area

1.0. Situation and Context

2.0. Ideas and Scenario Planning

3.0. Research and Knowledge Gathering

4.0. Experiments and Outcomes

5.0. Decisions and Further Improvements

APAC – NAS – On-Premise

APAC – SAN – On-Premise

APAC – Volumes – On-Premise

APAC – Volumes – Cloud

APAC – Object Storage – Cloud

/ /

/ /

Sample Cost Estimation Matrix

As of 2018 07 25 : DMC

Noteworthy data point is not just storage capacity but storage throughput and characteristics (IOPS, SSD or Magnetic, 100% Magnetic, 100% SSD, Rightly Distributing what can be SSD and what can be Magnetic, etc).

Additional historical and industry benchmark, purely from IaaS compute perspective: Typically like for “like” for standard workloads, GCP is 10-15% less expensive than AWS; AWS is 10%-15% less expensive than Azure.

Variances happen when you start utilising key infrastructure and platform components where certain CSPs are better than others.

Above estimations did not consider

• volume discounts, reserved instances, or sustained use discounts which allow for significant estimation reductions;
• and dynamically provisioned and de-provisioned resources which also improve both development and operational characteristics of most cloud architectures compared to purely on-premise infrastructure.

E.g.

GCP has the best disk array mesh and global fibre network hands down to support their own globally-oriented data requirements; AWS will have more costs once cross-region activities are needed vs GCP; Azure is generally more expensive but has the best enterprise package integrations (e.g. Office 365 applications + Azure is more manageable and cheaper than Office 365 applications with Azure + GCP).

Other variations can occur when distinct offerings are used at varying degrees, like, Reserved Instances (1 or 3 years?) to cover for median workload requirements and dynamically allocated instances for known and unknown capacity surge. This is highly dependent on the software architecture and deployment maturity.

/ /

to start of metadata

Domains

Identity and Privileged Access Management

Detection and Diagnostics

Infrastructure Level Protection Controls

Data Level Protection Controls

Application Code Level Protection Controls

Incident Management

Key Guiding Principles

Authentication

Role-Based Access Controls

Separation of Duties

Least Privilege

Appropriate Authorisation

Audit and Traceability

Automation of Security Components and Practices

Data Governance and Stewardship

Multi-Layer and Multi-Modal Defence

Preparations and Simulations

Supporting Services – On-Premise

Supporting Services – Cloud – Azure

Supporting Services – Cloud – Google

Activities

/ /

/ /

/ /

Core Functions
Identify
Business Context
Resources
Related Cybersecurity Risks
Categories
Asset Management
Business Environment
Governance
Risk Assessment
Risk Management Strategy
Protect
Categories
Access Control
Awareness and Training
Data Security
Info Protection Processes and Procedures
Maintenance
Protective Technology
Detect
Categories
Anomalies and Events
Security Continuous Monitoring
Detection Processes
Respond
Categories
Response Planning
Communications
Analysis
Mitigation
Improvements
Recover
Categories
Recovery Planning
Improvements
Communications

Implementation Tiers
1:  Partial
Risk Management Process
Not formalised
Ad hoc
Prioritisation of cybersecurity activities
not directly informed by organisational
risk objectives, threat environment, or
business/mission requirements
Integrated Risk Management Program
Limited awareness at organisational level
Irregular, case-by-case basis
Varied experience or information gained
from outside source
May not have cybersecurity processes that
enable cybersecurity information to be
shared within the organisation
External Participation
Does not understand its role in the
larger ecosystem, dependencies/dependents
Does not collaborate with or receive
information from other entities
Does not share information
Generally unaware of cyber supply chain risks
of products and services provided and used

2:  Risk Informed
Risk Management Process
Approved by management
Not established as organisation-wide policy
Prioritisation directly informed by
organisationl risk objectives,
theat environment, or
business/mission requirements
Integrated Risk Management Program
Organisational awareness of cybersecurity risks
Approach to managing cybersecurity risks
not yet established
Cybersecurity information is shared
in organisation on an informal basis
Cyber risk assessment of organisational and
external assest occur but typically
not repeatable or reocurring
External Participation
Understands its role in the larger
ecosystem either with dependencies
or dependents but not both
Collaborates and receives some information
from other entities
Generates some of its own information
but may not share with others
Aware of the cyber supply chain risks associated
with products and services provided and used
but does not act consistently or formally

3:  Repeatable
Risk Management Process
Formally approved and expressed as policy
Cybersecurity practices are regularly
updated based on application of
risk management processes to
changes in business/mission requirements
and changing threat and technology landscape
Integrated Risk Management Program
Organisation-wide approach to manage
cybersecurity risk
Risk-informed policies, processes, and procedures
are defined, implemented as intended, and reviewed
Consistent methods in place to respond
effectively to changes in risk
Personnel possess the knowledge and skills
to perform their appointed roles/responsibilities
Consistently and accurately monitors
cybersecurity risk of organisational assets
Senior cybersecurity and non-cybersecurity
executives regularly communicate regarding
cybersecurity risk
Senior executives ensure consideration of
cybersecurity through all lines of operations
External Participation
Understands its role, dependencies, and dependents
in the larger ecosystem
May contribute to the community’s
broader understanding of risks
Collaborates with and receives information from
other entities regularly that complements
internally generated information, and shares
information with other entities
Aware of cyber supply chain risk associated with
products and services provided or used;
formally acts upon risks, including mechanisms
such as written agreements to communicate
baseline requirements, governance structures,
and policy implementation and monitoring

4:  Adaptive
Risk Management Process
Adapts its cybersecurity practices based on previous
and current cybersecurity activities, including
lessons learned and predictive indicators
Through a process of continuous improvement,
incorporates advanced cybersecurity
technologies and practices;
actively adapts to a changing threat
and technology landscape
Timely and effectively responds to
evolving, sophisticated threats
Integrated Risk Management Program
Organization-wide approach to managing cybersecurity
risks, using risk-informed policies, processes,
and procedures to address potential
cybersecurity events
Relationship between cybersecurity risk and
organisational objectives is clearly understood
and considered in decision making
Senior executives monitor cybersecurity risk in the
same context as financial and other risk
Budget is based on an understanding of current and
predicted risk environment and tolerance
Business units implement executive vision and
analyse system-level risks in the context of
organizational risk tolerances
Cybersecurity risk management is part of the
organisational culture, evolves from previous
and ongoing activities on systems and networks
Can quickly and efficiently account for changes
to business/mission objectives in how risk is
approached and communicated
External Participation
Understands its role, dependencies, and dependents
in the larger ecosystem
Contributes to the community’s broader
understanding of risks
Receives, generates, and reviews prioritised information
that informs continuous analysis of its risks as
threats and technology landscape evolves
Shares information internally and externally
Uses real-time or near real-time information to
understand and consistenly act upon cyber
supply chain risks associated with products and
services provided and used
Communicates proactively using formal and informal
mechanisms to develop and maintain strong
supply chain relationships

/ /

20180808

Move List

Key Drivers and Strategic Plans

Known Parameters

Critical Constraints

Blockers

Unknowns

Contingency Plans

Paths Forward

Organisational Restructuring

Property Repurposing

? ? ?

Current Infrastructure & Application Landscape

Current Personnel, Roles, Leadership, and Hierarchies

Global Considerations

Regional Considerations

Local Considerations

Vendors

? ? ?

Global Services

Location

Middleware

Miscellaneous

MS SQL Server

Multicast

SAN Replication

Others

External Dependencies

Internal Dependencies

Timeline

Budget

Technical Incompatibilities

Actual TCO

Downsides and Consequences

Opportunities for Improvements

Opportunities for Optimisation

Opportunities for Transformation

Commitments

Future Preparedness

Contingency Plans

Organisational Restructuring

Extend or Move Forwards Timetables

  Increase Organisational Preparedness

Property Repurposing

Colocation Facilities

Constraints

Further Due Diligence

  Further Enablement

Ideas – Perspectives

Existing Non-Critical Execution and Data Paths

What We Don’t See In The List

Non-Existent, Future Systems

Non-Existent, Future Architectures and Design

/ /

Account Structure

Billing

IAM

Networking

Security

Logging

Services

Compliance

IaaS

Operational Process

/ /

Most CSP will have their own take of organisational accounts structure, given. No extremes but there are nuances.

AWS and Azure enforces heavy first with hierarchy for accounts/billing then augments lightly with IAM roles, service policies, and token-based auth/auth.

GCP espouses opposite ethos: enforces lightly on account hierarchy, some differences in billing structural associations, and augments heavily with roles, resource grouping, and swarms of projects.

This is in a way a reflection of organisational cultures underpinning providers themselve where none is really better than another, in the purest sense. Strategies are best aligned first with end user organisation contextual structures. Are we more of GCP’s ‘natural’ structure or Azure’s?

Guess, we choose one with most alignment with linchpin components (Servers? Services? Office 365? On-premise AD structures?).

How will we be using GCP services vs Azure services, by the way, apart from IaaS, PaaS, and SaaS qualifications? Will there be overlaps?

Does everyone in AD (on-premise or otherwise) really require accounts in GCP? Or will full sync happen only between AD (multi-purpose) and AAD (primarily for Office365, then others)? Possible to have subsets of roles / accounts only in GCP Cloud Identity?

There will always be a level impedance, regardless if bias exist between 2 providers or if this is refereed by a 3rd service as arbiter (e.g. Ping; Okta; Etc.).

/ /

Technically, there are tactical structures, thinking, and activity with AWS and Azure that are intrinsically driven by underlying service component.

E.g.

VPC and Subnet and etc structures are driven by shaped by how AWS and Azure typically have regional networks with zonal subnetting features. A lot of environment structure strategies, shared vpc peerings, and VPN (IPSec / SSL) / Direct Lines, are following paths of least resistance based on network features. This is both driven by their organisational business fault lines and their use of 3rd party internet-scale data centre land lords.

Some of these considerations may not be relevant in GCP where networks are global and subnets/other networking components are logically and easily regional or zonal, owing to its natural SDN-defined global networks and data centres are primarily owned by Google itself.

/ /

Not an opinion, mostly what we have seen or have done in last couple of years for GCP/GAE/Hybrid. Surely, many many other ways.

Have only seen so far, startups, enterprises, governments, and even with Googlers at least either:

Project per application/system per environment type (all permutations)
Project per application/system with primary grouping for Non-Production (x-build, x-test), Production (Staging, Production, Disaster Recovery), Tooling (e.g. Deployment tools […], Management tools, Monitoring tools, etc)
One big thing (in some contexts, everything is “production-like” in regulatory/technical treatment and environment segregation are very loose/dynamic)

Main aspect considered are three things:

Billing structure concepts in GCP and easy changes that can be made in association with “projects” (for good and bad)
Greenfield or Migration parameters
Internal and External interactions of people/service accounts

Practically, by people or by software, which is more complex:

thingamagigs-3141592
whatchamacallit-2718281
fx-this-dev-etc-then-some-id
fx-this-test-etc-then-some-id
cp-this-dev-etc-then-some-id
cp-this-test-etc-then-some-id
fx-this-dev-etc-then-some-id/:api-here
fx-this-dev-etc-then-some-id/:api-there
fx-this-test-etc-then-some-id/:api-here
fx-this-test-etc-then-some-id/:api-there
cp-this-dev-etc-then-some-id/:tcp-that
cp-this-dev-etc-then-some-id/:tcp-that
cp-this-dev-etc-then-some-id/:upd-that
cp-this-test-etc-then-some-id/:upd-that
Regardless of patterns/conventions, Delimiters always make it easier to parse (by humans or software, with no need for complex mapping that requires complex tooling, etc)

The “project” in GCP is like Accounts in AWS and Azure. It is not “project” in the typical/logical notion we use the word for. Practically, a final complete structure may not be feasible at this very point, though.

Transition phases are always the trickiest bit, organisationally and technically. But decision has to be made appreciating that some tactical aspects of this will change, as long as we don’t break key fundamentals and that we are sensitive to the nuances and differences of various services.

1>

How is everyone over there currently running provisioning and orchestration scripts? Via cloud shell only? Jump/bastion server? Permitted workstations / roles?

2>

Moving forward, how will this work? Do we provision jump/bastion hosts from which we rotate RSA keys on for allowed staff/robot/automation OS accounts? Or purely depend on cloud shell / triggered scripts (how if Terraform? Internal tool available to front it or controlled SSH)?

3>

For MFA / 2FA / FIDO U2F, what will be the user/service-bot tiering, assignments, rotation? Supplemented by Yubikeys / G Auth mobile?

CyberArk, as mentioned above, proven in our context to work already in the MFA / 2FA workflow with GCP?

4>

How will control of the lifecycle be managed/relayed (process[create, update, delete] x roles [robot, cloud admin, cloud support, etc])?

E.g.

A tool or script or person provisions instances/services (GCP/Azure console, or script, or tool that calls SDK/API/Script) then what/who (or same instances/services),
relays information/access to next step in process (updates/patches on top of current OS build?),
relays stable instance ready state for application / system deployment (with tool [teamcity, jenkins, scripts, msdeploy, etc] or console or custom script?)
relays to optional time of day operational lifecycle, considered at the moment or assume active instance 24/7)
Decommissioning steps and parameters
. . .
. . .
. . .

Any suggestions for further assessment and preparations, very much appreciated.

/ /

Cloud Relevant Domain Considerations

Cloud – Key Guiding Disciplines

Cloud – Supporting Services – On-Premise

Cloud – Supporting Services – Azure

Cloud – Supporting Services – Google

Cloud – Key Activities – Azure

Cloud – Key Activities – Google

/ /

Sample

Leverage various channels GCP allows for cognitive hooks; they, like most cloud providers, understand that there are no one-size-fits-all and redundancy is needed for convenience.

name: Human-readable, Functionally easy to discuss

projectID: More structurally consistent in terms of taxonomy and hierarchy

projectNumber: Service-Oriented, Inventory and Lifecycle Management Oriented

Other labels/tags: Redundancy, Extensible Tooling and Aspects Management, Non-Destructive and Non-Disruptive Change Hooks

{
  "name": "myproject",
  "projectId": "my-project-123",
  "labels":
   {
     "my-label": "prod"
   },
   "projectNumber": "464036093014",
   "lifecycleState": "ACTIVE",
   "createTime": "2016-01-07T21:59:43.314Z"
}

Something to think about and decide on at some point.

/ /

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

http://www.techguru.cloud/post/terraform-gcp/

/ /

Summary Principles

1. Exit first, Optimisation second
2. Buy Infrastructure Services over Building and Managing it ourselves
3. Automate Everything
4. Cloud Portability
5. Minimise Legacy, upgrade and standardise
6. Optimise for Infrastructure Cost
7. Optimise for Operational Cost
8. Least Access Privileges

Detailed Principles

References

• https://confluence.dts.fm.rbsgrp.net/display/NWMC/Guiding+Principles
• https://confluence.dts.fm.rbsgrp.net/display/NWMC/Migration+Principles
• https://confluence.dts.fm.rbsgrp.net/display/TWG/Principles
• PCA – Design – Principles

/ /

List of trainings available on RBS Skillport

An Introduction to Basic Cloud Concepts
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cc_uccf_a01_it_enus

Cloud System Architecture – Concepts and Design
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_csip_a01_it_enus

Cloud Computing Fundamentals: Overview
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_cctf_a01_it_enus

Cloud Computing Fundamentals: Storing and Managing Cloud Data
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_cctf_a03_it_enus

Cloud Computing Fundamentals: Cloud Security
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_cctf_a06_it_enus

Cloud Computing Fundamentals: Migrating to the Cloud
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_cctf_a04_it_enus

Cloud Computing Fundamentals: Virtualization and Data Centers
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_cctf_a02_it_enus

Cloud Computing Fundamentals: Identity, Presence, and Privacy
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_cctf_a05_it_enus

Cloud Computing for the Business User: Concepts and Moving to the Cloud
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_ccbu_a01_it_enus

Google Cloud Basics
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/it_clgcar_01_enus

Google Cloud Platform Fundamentals
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_gcde_a01_it_enus

Container, Compute, and App Engine with Networking Services
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/cl_gcpf_a02_it_enus

Google Cloud Design
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/it_clgcar_02_enus

Google Cloud Network Components
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/it_clgcar_03_enus

Google Cloud Data Storage
https://rbs.skillport.com/skillportfe/main.action?path=summary/COURSES/it_clgcar_05_enus

/ /