Data Analyst Professional · Модуль 14 · Урок 48 із 51
Персональні дані, доступи й мінімізація
Безпечний аналіз починається не з маскування фінального dashboard, а з рішення які дані справді потрібні, для якої мети, кому, на який строк і на якому grain. Мінімізація зменшує impact ще до access control.
Data inventory до імпорту
| Поле | Питання | Рішення |
|---|---|---|
| Purpose | Яке рішення неможливе без цього field? | видалити, якщо немає purpose |
| Classification | Public, internal, confidential, restricted? | застосувати policy owner |
| Grain | Потрібен user-row чи достатньо cohort/week? | агрегувати якомога раніше |
| Identity | Чи потрібна пряма ідентифікація? | pseudonymous key, separate mapping |
| Retention | Коли purpose завершується? | expiry, deletion і evidence |
| Export | Що може залишити controlled service? | allow/deny + label + owner |
Data minimisation — не «зберемо все про запас»
Стаття 5 GDPR формулює принцип: personal data мають бути adequate, relevant і limited to what is necessary for purpose. Для курсу це практичний engineering rule, а не юридична консультація: використовуйте synthetic data для портфоліо, зменшуйте columns/rows/detail і документуйте purpose.
Pseudonymization не робить data автоматично anonymous
Stable user key може бути повторно пов’язаний з особою через mapping або інші ознаки. Mapping зберігайте окремо, доступ обмежуйте, а ризик re-identification оцінюйте.
Least privilege як матриця
Principal / group | Asset | Action | Purpose | Expiry | Owner
Analysts | curated model | read/build | analysis | 90d | Data owner
Report viewers | report/app | view | decision | role term | Business owner
Refresh service | source/table | read | refresh | rotation | Platform ownerNIST визначає least privilege як достатні права для призначеної функції — і не більше. Надавайте доступ групам, відокремлюйте read/build/write/admin, додавайте expiry і регулярно прибирайте orphan access.
Мінімальний secure workflow
- Collect: approved source, purpose, lawful/organizational basis і owner.
- Transform: types, deduplication, pseudonymization, aggregation, small-cell suppression.
- Store: controlled location, encryption, secrets outside files/code.
- Use: group-based access, least privilege, RLS/OLS where appropriate.
- Share: recipient, export, public/private rule, label і expiry.
- Delete: retention trigger, backup scope і logged completion.
Threat review для аналітичного артефакту
Email, phone, customer name, credentials або private URL.
Мала cell чи рідкісний segment видає особу.
Viewer має Build/Write або source export.
Contractor/employee пішов, role лишилась.
При інциденті не редагуйте історію мовчки: revoke share/link, preserve facts/logs, notify owner/security path і задокументуйте scope. Не публікуйте секрети у screenshot «для доказу».
Практика
Завантажити capstone pack (.zip)
- Заповніть access-review для PBIX, evidence register і public screenshots.
- Видаліть поля без explicit purpose.
- Переведіть user-level output у cohort/segment grain.
- Додайте owner, group, role, export rule, expiry й review date.
- Проведіть leak/inference/stale-access challenge.
Офіційні джерела
Готовність до тесту
Ви мінімізуєте data за purpose, розділяєте pseudonymous та anonymous, проєктуєте group-based least privilege і керуєте retention/export.
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.