Shadow IT – Tradeoff between frictionless user experience and being responsible with AAD V2

Introduction

First let me begin with ‘What is meant by Shadow IT ?’. In a broader view shadow IT is, any sort of IT usage without the direct governance of IT department of your organization.

Sometimes this remains as a violation of the company policies, but the proliferation of the cloud SaaS applications and BYOD trends makes shadow IT an unavoidable practice.

100-cloudtweaks-comic

A simple example would be a cloud based file sharing application used in an organization which is not officially approved by the IT.

In most cases organizations are not aware of the tools used by their employees and shadow IT usage. Only 8% of the organizations are aware of their shadow IT usage.

percentage shaow it

Taken from – Cloud Adoption Practices & Priorities report 2015 : Cloud Security Alliance.

In my opinion there are two major reasons which fuel the increasing shadow IT practices. First, when employees have higher and diversified devices than the ones available at work. Secondly when they find sophisticated SaaS tools than the ones available at work.

Another notable reason is – communication between contextual boundaries, like departments, SBUs and other companies – people tend to use cloud based SaaS tools either for convenience or due to some already existing shadow IT practices of a party.

How to with AAD V2

So, what is the importance in software development in shadow IT ? –  One of the projects I’m involved with has been going through the transformation of being an internal system to a public system. We decided to open this up as a SaaS tool that anyone with a Azure Active Directory (AAD) credential can use it.

Behind the scenes the application has rules to track the user, tenant, recurrence of the tenant, other users in the tenant and the list grows. But anyone with a valid AAD account can simply create an account and start using it. This makes the application a perfectly fitted candidate in Shadow IT. It’s a perfect Shadow IT tool.

As SaaS provider we want many users as possible using our system, after all we charge per transaction 🙂

  • The application is registered as a AAD V2 app in the home directory.
  • We removed the friction in the enrollment by keeping only the minimal delegated permission (User.Read) in the app.

But in order to provide more sophisticated experience inside the application we require access to AAD and read permissions on other users. In order obtain this we thought of an approved shadow IT practice via application permissions.

  • We added the admin privileges to the application permissions, and generated application secrets.

The configured AAD V2 app principle look similar to the below one.

b1.PNG

In the experience point of view, we trigger the typical following normal AAD login URL for the user login. We trigger the organization endpoint (restrict the Microsoft accounts) with the following URL. (You can try the URL)

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?client_id=412e0485-15f1-4df6-be94-25ce5fcc62db&response_type=id_token&redirect_uri=https://localhost:8080&scope=user.read openid profile&nonce=3c9d2ab9-2d3b-4

This will popup the login and after the successful validation of the credentials you’ll see the following consent screen.

b3

User accepts the consent and she’s inside the SaaS application Shadow IT begins here. In order to get the additional rights we allow the user to inform her IT administrator and ask for additional permission.

IT administrator will be notified by the email entered by the user with following admin consent link.

http s://login.microsoftonline.com/[tenantid]/adminconsent?client_id=412e0485-15f1-4df6-be94-25ce5fcc62db&response_type=id_toke&redirect_uri=https://localhost:8080

Here we obtain the tenant id from the id_token from the user logged in previous step. When the IT administrator who has admin rights in the AAD hits the above URL and after successful validation of the credentials he will see the following admin consent screen.

b4.png

The permission list varies based on the configured application permissions in the application. After successful consent grant, the redirection will happen to a URL similar like this

http s://localhost:8080/?admin_consent=True&tenant=[tenant id]

Now the application can use the app secret to access the specific tenant.

NoteFrom AAD principle point of view, the service principle of the application is registered in the tenant in the first step. (This configuration should be allowed in AAD – by default this is enabled) and during the admin consent process the service principle gets more permissions granted to it. 

Summary

We achieved both the frictionless experience for the user and allowing administrator to grant the permission when required. The below image summarizes the process.

b5

  • By request IT admin knows the usage of application and it give some light to the usage of such SaaS.
  • By granting access IT admin allows it to the organizational use and removing shadow IT context.
  • If admin rejects the consent the organizational user knows that he’s in Shadow IT context.
  • Blocking of such SaaS may continue based on the organizational policies.

 

 

 

 

 

Advertisement

Understanding GDPR and personal data

General Data Protection Regulation (GDPR) the law imposes new rules on companies, government agencies, non-profits, and other organizations that offer goods and services to people in the European Union (EU), or that collect and analyze data tied to EU residents. The GDPR applies no matter where you are located.

I have been reading the key aspects of the GDPR from the above official site, and thought to summarize the points I came across in order to understand what GDPR is, how we can make the systems complaint to the GDPR.

  1. GDPR is a regulation will take effect in May 2018
  2. It gives more control to the EU citizens over their personal data
  3. GDPR enforces controls over data collection, usage, storage, handling breaches, transparency, expiry and etc.
  4. GDPR puts non-technical regulations as well, in few scenarios. Ex – A must to have data security officer in organization in certain scenarios.
  5. It does not explicitly mention on encryption or end-to-end data protection but the regulatory requirements will force the applications deal with personal data to use those technologies.
  6. Strict security audits, logs and documentation should be in place in order to be complaint with the GDPR.

GDPR defines ‘personal data’ as – any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person.

According to the definition name, address, credit card number, social security number, bank account number, telephone number, license number, vehicle number and any other explicit identification information is a personal data. But the following types of data also fall under the personal data category.

  1. Calls to customer care services or any other voice based services where they record the voice of the user. Though the voice record takes place without the name and with the full anonymity, still the voice data itself should be treated as a personal data.
  2. Any video surveillance recordings (CCTV) or any other visual recordings should be treated as personal data (both in the edge and cloud storages).
  3. Any forms of biometric data should be treated personal data.
  4. Drawings which represents the state of a real image like drawing of a portrait, a family or anything which exhibits the behavior of socio cultural aspects of a family or an individual can be considered as personal data.
  5. Value of an asset – this is a number but still considered as a personal when it is linked with the a person’s profile and can be used to guestimate the economic state and the obligation of the person.
  6. Call logs and any other data usage logs.
  7. Real-time geo location monitoring and geo-location data. Ex –  Uber drivers
  8. Meeting minutes and any forms of such data for official purpose which any relatable links or traceable information to a person.
  9. Any sort of medical imagery with traceable information.
  10. Photos, videos and voice recordings of any person on any sort is a personal data.
  11. Any non-aggregated data which reveals consumer patterns on goods and services.
  12. IP addresses – including dynamic IPs

The above list is does not include all, but summarizes the personal data in short from the above link. In my opinion any data seems to be a personal data as long as it can be traced and tracked to a person.

In certain scenarios GDPR ensures the organizations to have non-technical complaints such as having a data security officer and etc.

Encrypting the personal data is a one aspect of GDPR which is covered by the clause of “pseudonymous data”. This does not make the solutions complaint to the GDPR because encrypted personal data is also considered as personal data, but this gives some relaxation on on security breaches and how the breach should be handled and notified.

In summary all the solutions should have the technical and non-technical aspects of

  1. Why we collect and store the personal data
  2. How the personal data is used
  3. Transparency of the usage and sharing policies of the personal data
  4. Store personal data as pseudonymous data
  5. Continuous security auditing and monitoring
  6. Notification to the users upon breaches and policy changes