build your application in a cloud. make it safe! deadline?...
TRANSCRIPT
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.