Build Your Application in a Cloud. Make It Safe! Deadline? Tomorrow!

Tomasz OnyszkoCTO, Co-Founder

Predica Sp. z o.o.

• Internation comapny based in US, Poland (HQ)

and Middle East

• 150+ consultants in 5 countries

• Projects delivered in 20+ countries on 3

continents

• Predica – CTO and co-founder

• (almost) 20 years in IT business

• MVP (since 2005 ... with short break)

• blogger: https://onyszko.com

• video: https://predica.pl (and our YT channel)

• twitter: @tonyszko

GOAL: Learn how to build secure application on Azure cloud using cloud services and architecture patterns!

What does it mean that application is secure?

SECURE – is it the same for everyone?

How do we know what to tacle and how?

Azure Security more than one aspect

• IaaS• Virtual machines, networking and its environment

• PaaS• Services provided by the platform with code deployed

• Mix• PaaS services based on infrastructure (e.g. AKS)

It is a lot of moving parts!

Azure is a sandpit!

• Who can enter a sandpit?

• Who can build sand castles and in which region?

• What sand resources are available and who can use it for what purpose ?

How Azure is built and who controls it!?!

• Subscription == „sandpit”

• Resources groups within subscriptions == „sand resources”

• Single organization can (and will) have many subscriptions (and will have to manage it)

Azure Active Directory - Gatekeeper

Azure AD

• Directory and more• Directory object store

• Unigied authentication and authorization service with scale

• In a context of Azure• Azure is just another app

• Azure resources access controled through Azure AD

• Role based security mode

User

Application

Groups

Role

RBAC

• Roles are defined at the level of• Subscriptions

• Resource groups

• Scope• Default

• Custom (defined within organisation)

• HINTs:• Do not use MSA accounts to grant access

• Group -> Role (avoid direct user to role assignment)

Lets build THE APPLICATION!

Simple case: Web Application

• What you need to provide?• Security context used by application

• Application permissions to access resources

• Authentication service for users

• How to deal with sensitive materials (connection strings, certs, passwords)

• HOW?

Security context

• Each application has two Azure AD objects• Application

• Service Principal

• Application (definition)• App metadata and configuration

• Service principal• App representation within particular tenant

Service principal

Application

Service Principal

• Why we need it ?!?

• Multi-tenant applications• Obsługuje użytkowników w wielu AAD

• Application object exists within original tenant

• Each tenant using an app has service principal

• Service principal• Local tenant user assinments and app permissions

• Local application branding

• Additional permissions and settings local for the tenant

Dear app, How DO I know it is YOU?

• Application credentials• ClientID (login)

• Secret (password)

• ClientID• Form of GUID, created once upon app creation

• Secret• Application key, can be created on request

• Each key has its validity perio

• Client Secret – problem!• How to deal with its expiration?

• How to protect it?

• What to do if someone will capture it?

• What if someone will commit it to VSTS/GitHub?

Managed Service Identity (MSI)

• Application and Service principal managed by Azure platform• Application keys managed and rolled-over by Azure

• You don’t need to generate and manage app credentials

• Credentials usage (access)• Through API and libraries from code

• Environment variables

MSI – where you can use it?

• IaaS (virtual machine identity)

• App Service

• Azure Function

• Azure Data Factory v2

MSI – what supports it?

• Azure Resource Manager (ARM)

• Key Vault

• Data Lake

• Azure SQL

• Event Hub

• Service Bus

How Azure Function should connct to database!?!

?

Azure KeyVault

• Service to store, manage and access• Passwords, keys, certificates, secrets (connection strings)

• Up to 10kB

• HSM (in Premium tier) accessible through API• Access is controled at Azure AD level

• Fully audited with access audit trail

Azure KeyVault in an APP

Connection string

Key Vault – Access control

• Controled on instance level (vault) • Multiple vaults will exists within single subscription

• Based on Azure RBAC model

• Permissions can be granted• For user, group or role (preffered)

• For application (service principal)

Key Vault – practical tips

• KeyVault is security boundary! • If we have separate security domains within app lets

separate Key Vaults for them

• Performance• Each operation on KeyVault is REST API call

• With large volume of calls it can hit your performance

• Think about caching at the application level

Admin portal Ogólny web

MSI MSI

Admin portal Ogólny web

MSI MSI

Applications today

User Browser

Native apps

Server apps

User

Web App

API

API

API

Applications today … in practice (real case)

User

Browser Web App API

Username and password

Basich HTTP Auth

Authorization key

Key crafted by hand for each “customer” and

passed in URL

Fixed service account

OAuth 2.0 for beginners

• It is protocol „framework” for authorization, sets protocol flows

• Authorization protocol designed to authorize “resources” access (mostly API)

o It doesn’t enforce and sets standard for authentication

o It doesn’t enforce or specify token validation

• OAuth token is designated for API, not to be consumed by application

o Access Token

o Refresh Token

• Specifies several protocol flows based on client and scenarios

OAuth trouble

• It is not authentication protocol

o And it is important distinction

• It is not strict protocol, details will vary (like scopes)

• Token security

o Security of refresh token

o Token hijacking

• Proof Key for Token Exchange

• Token binding

OpenID Connect for beginners

• Based on OAuth 2.0

o Federation protocol

o Based on JWT

• It is authentication protocol, specified ID Token

o Standard scopes

o Introduces user info endpoint

• Standard way of token validation and verification

o Discovery endpoint

OpenID Connect at a glance

• Solves authentication problem for client

o Dedicated identity token

o Well defined requirements for authentication and token validation

• Scalable

o Discovery endpoint

• Based on OAuth 2.0

o Support all Oauth 2.0 authorization flows

• Ineterop!! - http://openid.net/certification/

Identity as a Service (IdaaS)

Identity != Authorization

Troubles with authorization

• Identity provider does not have all the knowledge about apps and

permissions

o Authorization process should be performed close to the resources

• Once issued token can be re-used in various places

o Single token used in different contexts

• Permissions are changing, tokens might live long

o Token revocation problem

Token re-use problem

API

API

API

Identity provider

Trouble with authorization continued

• There is more than one permission in an application

o Permissions for client to access API

o Permissions for user to use application function

o Permissions for user to use API functions

o Permissions for user at data level

o Uprawnienia użytkownika na poziomie danych

• Different syntax and semantics of permissions at different layers

Bloated token{

"iss": "https://idp",

"aud": [ "api1" ," api1"],

"alg": "HS256",

"amr": [ "password" ],

"auth_time": 1234567890,

"typ": "JWT"

"sub": "1234567890",

"name": "John Doe",

"admin": true

"role": [

"Approver",

"Reviewer" ],

"permission:" [

"CreateRecord",

"ViewRecord",

"DeleteRecord",

"ApproveOrder" ]

}

metadata

Identity information

role

permission

Authorization in apps

Authentication and token issuance

Client permission

Identity provider Authorization provider

API calls

API specific permissions

In summary

• Application security is something you need to address at the design level• Identify threats, address risks

• Address most important aspects first!

• Azure platform• Provides complete security model for applications (with some

details still to be addresses)

• Provides services which address many security aspects

We even haven’t started to talk about …

• Infrastructure

• Encryption

• Data at rest

• Data in transit

• Within services

• Audit and monitoring

• Handling user identity (consumer and other security aspects)

THANK YOU!

More, not only on security?

https://predica.pl/blog/

Tomasz OnyszkoCTO, Co-Founder

Predica Sp. z o.o.