Education Insights – support students through data, responsibly.

by Contributed | Jun 20, 2022 | Technology

This article is contributed. See the original author and article here.

Education Insights aims to facilitate data-driven decisions, as we believe that data-informed educators and education leaders make the most significant impact in their schools.  As an education professional, supporting students’ learning journeys while protecting their wellbeing is what you do. We’re here to help you identify needs and provide support from an informed perspective. We also highly value individual and organizational privacy and are committed to defending and protecting privacy for every student.

For those reasons, we provide Education Insights with attention to maintaining the highest external compliance standards, meeting GDPR, FERPA and other industry standards, as well as our own rigorous ethical and responsibility standards as established by Microsoft principles for Responsible AI.

In this blog, we will review some of the guidelines and practices Education Insights uses to help you leverage data to support your students, while maintaining peace of mind regarding your students’ data privacy and security. Additionally, we will provide some suggestions for to how to communicate Education Insights to your school community.

Guidelines and practices 

1. High compliance standards  

The information collected and shown through Insights meets national, regional, and industry-specific regulations for data collection and use, including GDPR and the Family Education Rights and Privacy Act (FERPA) for students and children’s security.

2. Students learning data only  

Students’ digital activity data collected by Insights includes only their activity in the context of the class and of the learning journey, such as accessing learning materials, participating in meetings, uploading a resume, etc. We do not collect information about students’ private activities such as message content or working on personal files. We also respect educators’ privacy, hence no activity data from educators is displayed

3. Supportive and non-judgmental language 

We believe that educators know their students best and are well positioned to make decisions about supporting their students. Education Insights doesn’t make judgements about students or educators. It aims to shine a light on student learning and digital engagement trends by providing meaningful activity data, leaving it up to the educator to follow up with students and to adapt instruction as they see fit.

4. Data access only for those who need it 

To preserve students’ privacy, each person in the school community has access only to data relevant to them:

• Educators can only see the activity of students assigned to their classes. They cannot access data from other classes unless a collaborating educator has shared it with them.


• Education leaders get an organizational view of their students’ activity that depends on their role, organization affiliation, and the permissions assigned to them by the IT Admin.

Education Insights data belongs to the school or institution. Microsoft simply collects the data, analyzes, and stores it. Microsoft engineering does not have direct access to student data and all access is strictly controlled, logged and audited, you can learn more about it here.

5. Transparency for everyone   

We are transparent in the data that is collected and how we use it. Each individual student also has a dedicated support page with authenticated access allowing them to see activity signals collected on them, along with instructions on how to contest the activity signals with their educators. Additionally, the IT admin can choose not to collect activity signals at any time; in which case Insights will not be available for the institution.

Communicating Education Insights to guardians and students 

While data is critical to thoroughly support students, and while Education Insights provides data with high standards of ethical use, privacy, and security, we also understand that it is vital to communicate clearly to students and guardians the collection of data and the value it provides.

Here is a suggested baseline for communication in case it would be helpful to start a positive conversation with guardians and students. You can also share this blog for further details and links to resources :)

Some technical details for you 

For those of you who are interested in some of the “backbone” of how Insights data is collected and stored:

Where do we store the ? Insights is deployed in Europe and the United States. Data for European-based users is stored on servers in Europe. Data for Australian-based and US-based users is stored on servers in the United States. Data for users outside of Europe, Australia, or the United States, will be stored in one of our geographic regions.

do we handle large volumes of data with high reliability? Insights leverages the power of Azure to ingest, process and store large amounts of signals in near-real time and with high reliability. All this is implemented on top of M365 secure environments. Each of these resources is provisioned in multiple geographical locations to honor the data locality explained above. Insights has a rich monitoring and alerting system which helps us track and mitigate potential data lost in the pipeline.

Learning more about data privacy in Education Insights 

• Education Insights Support articles


• Guidelines for the ethical use of Education Insights course


• AI business school for education course


• Microsoft principles for Responsible AI


• Microsoft trust center


• IT admin documentation

We’re always looking for ways to make Education Insights better. Have questions, comments, or ideas? Let us know! Add your ideas here or share your comment below.

General availability: Azure Data Explorer connector for Power Automate, Logic Apps, and Power Apps

by Contributed | Jun 19, 2022 | Technology

This article is contributed. See the original author and article here.

Row-level security in Azure Database for PostgreSQL – Hyperscale

by Contributed | Jun 18, 2022 | Technology

This article is contributed. See the original author and article here.

Row-level security (RLS) provides an important layer of security and is available as of PostgreSQL 9.5. It is also frequently used to implement data security for multi-tenant and SaaS applications. In this article, we will look at row level security on Azure Database for PostgreSQL – Hyperscale (Citus) to help you better understand how this feature might be used to implement data security in your application.

Before we get to RLS, here’s how Azure Database for PostgreSQL – Hyperscale helps with the distribution (sharding) of data. It brings the sharding logic to data layer and manages the shards across the nodes which make up the server group. Once you choose a relevant distribution key, Citus distributes the data. If you are a SaaS provider, the distribution key could be customer / tenant identifier. In such a case, with RLS, you can ensure the right set of data is visible to different users of the database across organizations while Citus can manage their data within single database cluster / server group.

Having looked at why, let’s jump right into how of this. We’re going to walk you through the steps to configure and test row level security in Azure Database for PostgreSQL – Hyperscale. You should start by Creating Azure PostgreSQL Hyperscale (Citus) instance / server group.

Once the hyperscale server group is created and ready for connection, let’s proceed with the next steps.

Create a Table and Load Some Sample Data:

We’re going to create a new schema which will hold the table(s) where we want to enable RLS. This is not really required but just to ensure that you get full understanding of how this should work in the real environment.

CREATE SCHEMA test1;

In this schema, we’ll create a distributed table and load some data into it.

Create table:

CREATE TABLE test1.events(

tenant_id int,

id int,

type text

);

Shard the table on ‘tenant_id’ column:

SELECT create_distributed_table(‘test1.events’,’tenant_id’);

Load dummy data into the table:

INSERT INTO test1.events VALUES (1,1,’push’);

INSERT INTO test1.events VALUES (2,2,’push’);

INSERT INTO test1.events VALUES (1,2,’push’);

INSERT INTO test1.events VALUES (2,1,’push’);

After adding this dummy data into the new table, next step is to add roles other than the default admin (citus) which will have access to data as per the need.

Add Additional Roles as Required:

To do this, you need to login to Azure Portal as the default role ‘citus’ isn’t given privileges to create new roles.

As shown below, once you navigate to the hyperscale server group on the portal –

Step 1 – click on ‘Roles’ under Server group management,

Step 2 – click on ‘+ Add’ to add new role

Step 3 – provide a name for the new role and assign a password to it.

For this exercise, we’ll create two roles, namely – tenant1 and tenant2. The reason we chose the role names is to ensure that shard key (in this case tenant_id) can be part of the name of the role and hence 1 and 2. You will see in the next section, why this is important.

Once this is done, grant privileges to these roles as needed.

Grant Required Privileges to the New Role(s):

Since we created a new schema to hold the distributed table, first step is to ensure that the new roles have access to this schema.

GRANT usage ON SCHEMA test1 TO tenant1, tenant2;

Without this step, if you try to assign privileges directly, PostgreSQL will return an error suggesting the role doesn’t have permission to access the schema.

Next, assign actual privileges on the table(s) to the roles.

GRANT SELECT, UPDATE, INSERT, DELETE

  ON test1.events TO tenant1, tenant2;

At this time, we have given the required privileges on the table to the newly created roles. However, if a user logs in with these, they will be able to see all the data across shards.

This is where the row level security comes into picture.

Configure Row Level Security:

To ensure that the primary role (citus) has access to all the data when we add new roles and enable RLS, create a policy which is applicable to this role:

CREATE POLICY admin_all ON test1.events

  TO citus           — apply to this role

  USING (true)       — read any existing row

  WITH CHECK (true);

Note that the policy will come into effect once row level security is enabled for the table.

The next step is to create a policy which will define the check on rows accessible by users.

CREATE POLICY user_mod ON test1.events

  USING (current_user = ‘tenant’ || tenant_id::text);

  — lack of CHECK means same condition as USING

The policy defines which rows user has access to as it concatenates string ‘tenant’ with the tenant_id column of the table. If you scroll back to where we created the roles and why we chose those names for the roles, it should make sense now.

And then finally enable the RLS on the table.

ALTER TABLE test1.events ENABLE ROW LEVEL SECURITY;

To further simplify this – the rows in the table have tenant_id values 1 or 2. Policy defines expression (‘tenant’ || ‘1’) as role name to have access to rows where tenant_id is 1 and so on. Of course, you need to create more roles as you keep adding rows to the table with different tenant IDs.

This check is pushed down to all the worked nodes in the hyperscale server group and will ensure that the access to the data is governed by the policy created by row level security.

This is it! Go ahead, login with the new role and try to fetch or change the rows in the table.

On the dummy data defined here, when ‘tenant1’ logs in and runs the following query –

SELECT * FROM test1.events;

The output is this –

This ensures that the role ‘tenant1’ only has access to rows with tenant_id being 1 and similarly role ‘tenant2’ will have access to rows with tenant_id being 2 and so on.

Stay tuned for more!

FastTrack for Azure: Move to Azure efficiently with customized guidance from Azure engineering. FastTrack for Azure – Benefits and FAQ | Microsoft Azure