Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / SharePoint 에이전트가 데이터를 유출한다면? 지식 소스 제한, 상속 끊기, Purview DLP 제대로 쓰기 (AI 더빙)

Transcript

SharePoint 에이전트가 데이터를 유출한다면? 지식 소스 제한, 상속 끊기, Purview DLP 제대로 쓰기 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
셰어포인트 에이전트가 정보를 유출한 것이 아닙니다.
0:02
소방호스를 건네주고는 한 모금만 마시라고 한 셈이죠.
0:05
지나치게 넓은 지식 범위와 허술한 권한 상속이 결합되면
0:08
기계적인 속도로 정보가 유출됩니다.
0:10
해결책은 마법이 아닙니다.
0:11
범위 제한, 권한 강화, 그리고 즉시 적용 가능한 정책 패키지로
0:15
무장한 강력한 DLP가 필요합니다.
0:17
에이전트가 데이터를 보는 방식, 그라운딩이 권한을 격리하지 못하는 이유,
0:21
그리고 유용성을 해치지 않으면 서 에이전트를 제어하는 방법을 알려드리겠습니다.
0:24
대부분의 관리자가 간과하는 설정 하나, 꼭 필요한 승인 단계, 그리고 실제로 에이전트를 차단하는 DLP 패턴이 있습니다.
0:31
에이전트가 보는 방식부터 시작하죠.
0:33
기초, 셰어포인트 에이전트가 실제로 데이터를 보는 방식, 즉 권한의 DNA입니다.
0:37
사실 에이전트는 사용자의 의도를 읽는 것이 아니라 마이크로소프트 그래프를 읽습니다.
0:41
그래프를 현류라고 생각하세요.
0:43
ACL을 통해 콘텐츠에 접근할 수 있다면 에이전트는 이를 읽어드립니다.
0:46
지식 소스의 범위를 지나치게 넓게 잡으면 세심하게 분류된 경로를 우회하는 통로를 뚫어놓는 것과 같습니다.
0:51
쉽게 설명해드릴게요.
0:52
에이전트는 사용자 페르소나와 검색 필터라는 두 가지 핵심 요소로 구성됩니다.
0:57
페르소나는 셰어포인트, 온드라이브 및 기타 연결된 모든 영역에서 해당 아이디와 그 권한을 의미합니다.
1:03
검색 범위는 라이브러리, 폴더, 파일 뭉치, 몇 개의 URL 등 에이전트가 지시받은 영역입니다.
1:09
대부분의 사람은 검색 필터를 보안 경계와 혼동합니다.
1:12
둘은 전혀 다릅니다.
1:13
검색 범위는 여기서 먼저 찾아라 라는 의미입니다.
1:16
권한은 들어와도 좋다는 의미입니다.
1:18
에이전트는 권한을 먼저 따르고 검색 범위는 그 다음입니다.
1:20
다른 건 몰라도 이 우선순위는 반드시 기억하세요.
1:23
민감도 레이블과 페뷰 DLP는 콘텐츠 위에 표집한 이나가드 레일처럼 자리합니다.
1:27
레이블은 분류를 수행하고 DLP는 특정 콘텐츠에 접근하거나 처리할 때 행동을 강제합니다.
1:32
대부분이 놓치는 핵심은 간단합니다.
1:35
그라운딩은 권한을 무시하지 못합니다.
1:36
그라운딩은 관련성을 필터링할 뿐입니다.
1:38
에이전트의 실제 권한 범위를 축소하지는 않습니다.
1:41
따라서 권한 상속을 그대로 두어 에이전트 아이디가 인접한 여러 라이브러리를 볼 수 있다면
1:45
LLM은 인근의 정보까지 가져와 답변을 구성할 수 있습니다.
1:48
이상한 일이 아니라 예견된 결과입니다.
1:51
권한 상속은 조용하게 권한을 확대합니다.
1:53
사이트가 내부용이라고 확신했지만
1:55
알고 보니 셰어포인트 그룹에 모두
1:57
나 인증된 사용자가 포함되어 있는 경우입니다.
1:59
게스트 계정이 남고 프로젝트 그룹 권한은 계속 유지됩니다.
2:02
에이전트는 분위기가 아니라 ACL을 준수합니다.
2:05
해당 아이디가 셰어포인트에서 파일을 열 수 있다면
2:07
DLP나 레이블 정책 조합이 에이전트 동작을 명시적으로 차단하지 않는 한 에이전트는 파일을 처리할 수 있습니다.
2:12
반일 라이브러리 파일럿이 갑자기 옆 라이브러리의 인사 규정을 인용하는 이유가 바로 이것입니다.
2:16
어떤 것도 격리하지 못한 것이죠.
2:18
잠기지 않은 방에 선호하는 선반 하나를 지정해준 꼴입니다.
2:21
최소 지식 원칙 모델을 도입하세요.
2:23
사이트 루트를 통째로 입력하고 관련성이 해결해주길 바라기보다
2:26
지식 소스를 특정 라이브러리에 묶으세요.
2:28
사이트 단위의 데이터 수집은 피해야 합니다.
2:30
폴더를 제한하고 메타데이터 필터를 사용하여
2:33
에이전트의 임무와 관련된 문서만 검색색인에 포함되도록 하십시오.
2:36
코파일럿 스튜디오 및 치어포인트 에이전트 빌더에서 공식 소스를 지정하고
2:40
일반 AI 지식을 비활성화하며 대체 응답을 추가할 수 있습니다.
2:44
권한이 없는 대체 응답은 당신의 안전벨트와 같습니다.
2:47
그렇지 않으면 모델이 규정 준수 상태를 따르지 않는 일반 지식으로 공백을 채우게 됩니다.
2:51
제한사항도 중요합니다.
2:52
플랫폼은 지식 소스 당 파일, 폴더, URL에 대한 실질적인 상한선을 부과합니다.
2:57
이는 단순한 성능 기록이 아니라 거버넌스를 위한 가드레일입니다.
3:00
한도에 도달했을 때 잘못된 본능은 잠시 범위를 사이트 루트까지 넓히는 것입니다.
3:05
그것이 바로 정보 유출의 시작입니다.
3:07
올바른 방법은 모든 권한을 가진 백과 사전식 보타나 대신
3:09
각각 엄격하게 제한된 소스를 가진 여러 개의 좁은 에이전트를 구성하는 것입니다.
3:13
지식을 분산하고 권한을 최소한으로 유지하십시오.
3:16
잠시 돌아가서 압박 속에서도 당신을 배신하지 않을 정신적 모델을 제시해보겠습니다.
3:19
에이전트는 사용자 페르소나와 검색 필터의 합입니다.
3:22
권한이 먼저 차단하고 검색은 그 다음입니다.
3:24
레이블은 민감도를 설명합니다.
3:26
dlp는 해당 민감도가 존재할 때 어떤 작업이 허용되는지 결정합니다.
3:29
그라운딩은 모델이 올바른 반락을 찾도록 돕습니다.
3:32
권한은 해당 반락을 볼 수 있는지 여부를 결정합니다.
3:35
dlp는 앞에 두 단계가 모두 승인하더라도 처리 불가 결정을 내릴 수 있습니다.
3:39
이러한 차단, 검색, 시행의 구조는 사고의 명확성을 유지해줍니다.
3:42
이 데이터 유출을 무시하면 ai가 이상하게 행동하는 것처럼 보이지만
3:46
실제로는 당신의 범위 설계가 허술한 상속과 충돌한 것입니다.
3:49
인접한 라이브러리는 권한 설정상 가까이 있기 때문에 모델에게도 가깝게 느껴집니다.
3:54
네, 모델은 당신이 강화하지 않은 경계를 넘어 사실 들을 기꺼이 엮어낼 것입니다.
3:59
이 내부 구조를 이해하면 다른 모든 것이 명확해집니다.
4:02
llm 이 답변하는 것을 탓하는 대신 모델이 무엇을 고려할 수 있는지 제어하기 시작하게 됩니다.
4:06
이제 현류와 척추, 그래프 권한 및 검색 필터를 이해했으니
4:10
물이 방을 넘어 흐르지 않도록 막아 봅시다.
4:12
계약서처럼 범위를 지정하고 상속을 끊고 진지하게 레이블을 지정하십시오.
4:16
첫 번째 제어 평면입니다. 변호사가 계약서를 읽듯 지식 소스의 범위를 지정하십시오.
4:21
이제 범위를 법률 용어처럼 정확하고 제한적이며 모호함을 허용하지 않는 방식으로 작성합니다.
4:25
광범위한 소스는 교차 간섭을 일으키며,
4:28
llm은 망원렌즈를 든 가시 칼럼 리스트처럼 주변의 사실 들을 기꺼이 엮어 답변을 만들어낼 것입니다.
4:33
여기 전문가와 초보자를 구분하는 범위 지정 규칙이 있습니다.
4:36
라이브러리 수준의 소스만 허용하십시오.
4:38
사이트 나이 허브 아래에 모든 것을 포함해서는 안 됩니다.
4:41
명시된 목적 당단 하나의 문서 라이브러리만 사용하십시오.
4:44
에이전트의 목적이 제품 FAQ에 답변하는 것이라면,
4:46
제품 FAQ 라이브러리 외에는 아무것도 제공하지 마십시오.
4:48
진실이 무엇일까요?
4:50
추가되는 모든 여분의 공간은 모델이 밀리초 단위로 활성화할 수 있는 잠재적 위험이 됩니다.
4:54
일반 사용자의 접근 방식과 비교해보십시오.
4:56
사이트 루트를 지정하고 하위 폴더를 추가한 뒤 메타데이터가 해결해주길 바라는 것은 위험합니다.
5:00
그렇게 되지 않을 것입니다.
5:01
검색 필터는 검색을 안내할 뿐 방화벽 역할을 하지는 않습니다.
5:04
따라서 법률가가 조항을 구성하듯 구체적이고 배타적이며 테스트 가능하게 범위를 설정해야 합니다.
5:08
실제로 활용할 수 있는 실용적인 범위 설정 메커니즘을 소개합니다.
5:11
사이트 루트 사용을 피하세요.
5:12
항상 구체적인 라이브러리 경로를 지정하십시오.
5:14
폴더 깊이를 제한하세요.
5:16
폴더를 반드시 사용해야 한다면,
5:18
제기적 포함 없이 얕은 수준에서 고정하십시오.
5:20
메타데이터 필터를 강제하여 상태가 승인됨,
5:22
버전이 개시됨,
5:24
부서가 X인 항목만 수집하세요.
5:25
메타데이터가 없으면 수집도 없습니다.
5:27
초한, 보관함,
5:28
작업용 하위트리는 제외하세요.
5:30
제외할 수 없다면 밖으로 옮기십시오.
5:32
네, 리팩토링 하세요.
5:34
그것이 바로 거버넌스입니다.
5:35
현실적인 한계를 확인하세요.
5:36
플랫폼은 무한한 버퍼가 아닙니다.
5:38
파일 개수, 폴더 제한, URL 할당량 등이 존재합니다.
5:41
이를 시스템을 유지하기 위한 속도 제한장치로 생각하세요.
5:44
코파일럿 스튜디오와 시어포인트 에이전트 빌더에서
5:46
서비스 시작 전 실제 한계를 테스트하세요.
5:48
실제 배포 환경과 유사한 파일들로 파일럿 소스를 만드세요.
5:51
승인된 PDF 수백 개,
5:53
도크X 매뉴얼,
5:53
PPT 몇 개면 충분합니다.
5:55
수집이 느려지거나,
5:56
시간 초과가 발생하거나,
5:57
임의로 건너 뛰기 시작하면 범위를 확장하지 말고 분할하세요.
5:59
소스당 하나의 도메인을,
6:01
에이전트 페르소나당 하나의 소스를 배정하세요.
6:02
이것은 오케스트레이션이지,
6:04
무분별한 수집이 아닙니다.
6:05
아무도 가르쳐주지 않는 지름길은
6:06
여러 개의 전문 에이전트가
6:07
백과 사전식 괴물 에이전트보다 훨씬 낫다는 점입니다.
6:10
인사정책 에이전트,
6:11
복리 후생 에이전트,
6:12
출장 에이전트 등
6:13
각각 고유한 라이브러리와 필터를 갖춘 에이전트를 만드세요.
6:16
반일 진입점이 필요하다면,
6:18
질문을 적절한 전문가에게 전달하는
6:19
라우터 에이전트를 전면에 배치하여 조정하세요.
6:22
전문가들이 이렇게 하는 이유는
6:23
거버넌스를 확장할 수 있기 때문입니다.
6:24
초보자들은 200개의 혼합된 도메인 파일을
6:26
하나의 에이전트에 몰아넣고,
6:27
답변이 왜 위원회 회의처럼 모호한지 위하여 합니다.
6:29
규제 대상 에이전트에서는
6:30
일반 AI 지식을 비활성화하세요.
6:32
에이전트가 특정 도메인에 대한 권한을 가진다면,
6:34
그 외의 영역에서는 침묵해야 합니다.
6:36
바로 여기서 대체, 폴백, 답변이 중요해집니다.
6:39
명확하고 겸손한 대응 방식을 설정하세요.
6:41
저는 해당 분야에 권한이 없습니다.
6:43
제가 다루는 승인된 소스는 다음과 같습니다.
6:45
일반 지식이 빈틈을 매우 도록 허용하는 순간,
6:48
레이블과 DLP 의도를 무시하는
6:49
검증 불가능한 상식의 세계로 돌아가게 됩니다.
6:52
큐레이션이 중요합니다.
6:53
공식 소스를 지정하세요.
6:55
이는 수집 단계 이전에 승인 워크플로우가 필요함을 의미합니다.
6:58
검토를 통과하고 정확성, 최신성,
7:00
민감도 레이블링이 확인된 콘텐츠만 추가하세요.
7:03
문서의 출처를 증명할 수 없다면,
7:04
에이전트가 답변해 사용할 자격이 없습니다.
7:06
모델은 자신감 있게 말할 뿐, 항상 정확한 것은 아닙니다.
7:08
당신의 큐레이션이 제동장치가 되어야 합니다.
7:10
오늘부터 당장 멈춰야 할 흔한 실수들입니다.
7:13
정책, 기술 문서, 공급업체 계약서 등을
7:16
하나의 소스에 몽땅 쏟아붓는 행위입니다.
7:18
목적에 따라 분리하고,
7:19
에이전트가 이미 웹URL을 크롤링하게 두세요.
7:22
아니요, 외부 URL은 공격 범위를 넓히고
7:24
감사 가능성을 떨어뜨립니다.
7:26
초안 인하 작담 파일을 수집할 때,
7:28
메타데이터와 위치로 구분하지 않으면
7:29
모델은 무엇이 미완성인지 게시된 것인지 알 수 없습니다.
7:32
숨겨져 있다고 해서 보호된다고 가정하는 것,
7:34
숨김은 UI 상위 선택일 뿐입니다.
7:36
권한이 곧 범위입니다.
7:38
테스트 규율을 지키세요.
7:39
범위는 실제로 테스트해야 하니까요.
7:40
엣지 케이스를 질문하고,
7:42
에이전트가 즉각 답해야 할 권위 있는 질문을 던진 뒤,
7:44
거절해야 할 인접 주제로 유도해보세요.
7:46
도메인 밖에 질문에 답한다면,
7:47
범위 설정이나 폴백이 잘못된 것입니다.
7:49
도메인 내의 질문을 거부한다면,
7:50
필터나 승인 절차가 너무 엄격한 것입니다.
7:52
튜닝은 더하는 것이 아니라 빼는 것입니다.
7:54
관련 없는 경로를 제거하고,
7:56
메타 데이터 모호성을 줄이며,
7:57
답변이 지루할 정도로 예측 가능해질 때까지 계속 쪼개세요.
8:00
그리고 추적해야 할 지표들입니다.
8:02
응답성,
8:03
위도된 라이브러리의 출처를 인용하여 해결된 도메인 내 질의의 비율입니다.
8:06
통제력,
8:07
승인된 소스만 인용하여 답변 한 비율입니다.
8:10
침묵 품질,
8:11
도메인 밖 질문을 받았을 때 폴백이 작동하는 명확성과 빈도입니다.
8:14
넘어가기 전에 체크리스트를 확인하자면,
8:17
라이브러리 전용,
8:18
얕은 폴더 구조,
8:19
엄격한 메타 데이터,
8:20
승인된 소스만 사용,
8:21
일반 지식 배제,
8:23
다수의 좁은 에이전트,
8:24
제한 테스트,
8:25
측정된 성과입니다.
8:26
이것을 고정하면 다운스트림의 권한,
8:28
라벨,
8:28
DLP 등 모든 것이 과도하게 범위가 넓은 엉망인 상태와 싸우는 대신 당신과 협력하게 됩니다.
8:33
이제 상속을 강화하여 파일 캐비닛 뿐만 아니라 방 전체를 잠가야 합니다.
8:37
제어평면 두 번째,
8:39
상속을 끊고 제대로 라벨을 붙이세요.
8:41
문이 활짝 열려 있다면 범위가 지정된 지식도 소용없습니다.
8:44
셰어포인트에서 상속된 권한은 보안의 낡은 물려받은 스웨터와 같습니다.
8:48
잘 맞지도 않고 구멍이 숭숭 뚫려 있으며 찬바람이 불기 전까지는 적당히 괜찮은 것 같죠.
8:52
에이전트는 낙관론이 아니라 ACL을 존중합니다.
8:55
그러니 중요한 곳에서 상속을 멈추고 고유 권한을 할당하며 내부를 사실상 인터넷 공개 상태로 만드는 광범위한 그룹을 제거하십시오.
9:02
불편한 감사부터 시작하세요.
9:04
민감한 라이브러리를 3개의 버킷으로 나누세요.
9:06
격리 필수, 공유 가능, 미확인 으로요.
9:09
미확인은 위험 신호입니다.
9:10
누가 접근 권한을 가지고 있는지 한 문장으로 설명할 수 없다면 입증되기 전까지는 격리 필수 항목에 포함해야 합니다.
9:15
그런 다음 각 격리 필수 라이브러리의 권한 상속을 끊으세요.
9:18
사이트 단위가 아니라 핵심 자산이 담긴 라이브러리 단위에서요.
9:21
상속을 끊는 것은 큰일이 아니라 성숙해지는 과정입니다.
9:25
명시적인 최소 멤버십, 소수의 소유자 그룹, 정의된 멤버 그룹, 그리고 업무상 필요한 경우에 읽기 전용 권한을 목표로 하세요.
9:31
이제 게으른 관리 방식을 척결하세요.
9:33
모든 사람, 외부 사용자 제외 모든 사람, 인증된 사용자와 같은 광범위한 그룹들은 마치 마트료시카 인형처럼 셰어포인트 그룹 안에 숨어 있습니다.
9:39
그것들을 제거하고 실제로 관리하는 역할에 맵핑된 에이저, AD 보안 그룹으로 교체하세요.
9:44
게스트는 예외적이고 일시적이며 식별 가능해야 합니다.
9:47
3년 전 프로젝트 시작 때 만들어진 셰어포인트 그룹에 중첩되어 있어서는 안 됩니다.
9:51
그룹 이름에 올, 전체, 이라는 단어가 포함되면 에이전트는 이를 뷔페처럼 여길 것입니다.
9:56
권한계층을 표준화하여 논리적으로 관리할 수 있게 하세요.
9:59
A계층은 기밀 라이브러리로 소유자, 구성원, 소수의 읽기 권한자만 허용하며 게스트는 제외합니다.
10:07
B계층은 내부 전용 라이브러리로 소유자, 구성원, 관리되는 읽기 권한자, 부서 그룹만 허용하며 외부인은 제외합니다.
10:15
C계층은 공개 내부 라이브러리로 소유자, 구성원, 모든 임직원이 읽을 수 있으나 역시 게스트는 제외합니다.
10:20
이 모델이 단순한 이유는 주의력이 흐트러지기 쉬운 사람이 이를 적용해야 하기 때문입니다.
10:24
에이전트는 여러분이 코딩한 대로 실행하므로 상식적으로 코딩하십시오.
10:28
민감도 레이블을 도입하세요. 레이블은 스티커가 아니라 정체키입니다.
10:32
기밀, 제한, 공개 등의 레이블을 특정 동작에 맵핑하십시오.
10:35
대부분의 관리자가 빠지는 함정은 레이블을 장식용으로 두는 것입니다.
10:38
이제 그런 방식은 그만두어야 합니다.
10:40
레이블을 퍼뷰 DLP와 연동하여 머신이 강제할 수 있는 의미를 부여하십시오.
10:44
예를 들어, 기밀 HR. 레이블은 사용자가 파일을 볼 수 있더라도 에이전트의 처리 작업을 차단하는 DLP 정책을 트리거합니다.
10:50
네, 맞습니다.
10:51
사용자는 시어포인트에서 읽을 수 있지만, 에이전트는 처리계층에서 거부당합니다.
10:56
이것이 판도를 바꾸는 핵심입니다.
10:58
레이블과 DLP는 인간의 가시성과 머신의 자동화를 분리합니다.
11:01
구체적으로 살펴보겠습니다.
11:03
기밀 HR로 레이블이 지정된 인사정책 라이브러리가 있다고 가정해봅시다.
11:06
인사 에이전트가 해당 라이브러리의 질문에 답변해야 합니다.
11:09
그렇다면 해당 에이전트의 아이디에 그 특정 라이브러리에 대한 읽기 권한을 부여하면 됩니다.
11:14
인사 업무 초안과 같은 인접 라이브러리는 에이전트 아이디가 접근할 수 없는 고유 권한으로 격리합니다.
11:19
동시에 DLP 정책으로 레이블이 기밀 HR이고 에이전트가 처리하려고 시도할 경우, 승인된 HR 에이전트 목록에 있을 때만 허용하도록 설정합니다.
11:29
열정적인 회사 지식 일반 에이전트를 포함한 다른 모든 에이전트는 차단됩니다.
11:34
이것이 누군가 실수로 잘못된 에이전트에게 권한을 주더라도 데이터 유출을 막는 방법입니다.
11:38
너무 많은 정보를 볼 수 있는 사용자의 경우는 어떨까요?
11:41
그것이 바로 조용한 권한 확대입니다.
11:42
사용자의 가시성에만 의존하면 사용자를 대신해 작동하는 모든 에이전트가 그 광범위한 권한을 상속받게 됩니다.
11:47
그러므로 에이전트의 아이디 권한을 좁게 유지하세요.
11:50
호출하는 사용자의 권한으로 실행되는 에이전트를 만들지 마십시오.
11:52
최소 권한을 가진 서비스 아이디로 실행되도록 구축하세요.
11:55
이를 네이블 및 DLP와 결합하면 권한 있는 사용자조차 에이전트가 범위를 벗어난 데이터를 처리하도록 속일 수 없습니다.
12:01
여러분은 설정 페이지에 기도하는 것이 아니라 제대로 된 방어 계층을 구축하는 것입니다.
12:05
이 계층을 망치는 흔한 실수들입니다.
12:07
숨겨져 있으면 안전하다고 가정하는 것.
12:10
프로젝트 사이트를 기본 상속 설정 그대로 두는 것.
12:12
벤더가 떠난 후에도 게스트 액세스를 유지하는 것.
12:15
더 최악은 더 쉽다는 이유로 광범위한 M365 그룹을 읽기 권한에 넣는 것입니다.
12:20
하지만 에이전트가 법무팀의 견적 내용을 영업답변에 포함시키면 이야기가 달라지죠.
12:24
그때부터는 사건 대응의 연극이 시작됩니다.
12:26
반복 가능한 구현 리듬이 필요합니다.
12:28
라이브러리를 격리하세요.
12:29
광범위한 그룹을 역할 별 그룹으로 교체하세요.
12:32
에이전트의 서비스 아이디를 할당하세요.
12:34
파일 및 라이브러리 수준의 민감도 레이블을 적용하세요.
12:36
그리고 명시적인 에이전트 허용 조건이 포함된 레이블에 DLP 정책을 연결하세요.
12:41
통제된 쿼리 세트로 테스트하세요.
12:43
도메인 내부 허용, 인접 영역 거부, 레이블은 있으나 승인되지 않은 에이전트는 명확한 메시지로 차단해야 합니다.
12:48
답변이 하나라도 세워나간다면 권한 설정이 잘못된 것입니다.
12:50
에이전트가 승인 없이 레이블된 콘텐츠를 처리한다면 DLP 맵핑이 잘못된 것입니다.
12:55
자기 합리화를 멈추고 맵핑을 수정하세요.
12:57
한 가지 더 주의할 점이 있습니다.
12:59
사소한 것들에 대해서는 사이트 상속을 유지해도 됩니다.
13:01
식당 메뉴판을 가지고 심장 수술을 할 필요는 없으니까요.
13:04
에이전트에 데이터를 제공하는 라이브러리 에만 고유 권한을 사용하세요.
13:07
그래야 관리자의 업무 부담을 줄 이면서 자동화가 접촉하는 지점들을 경고히 보호할 수 있습니다.
13:12
상속을 끊으세요.
13:13
최소한의 고유 그룹을 사용하세요.
13:15
유출은 곧 금전적 손실임으로 돈을 다루듯 네이블을 지정하세요.
13:18
그런 다음 네이블을 DLP와 연결하여 사람이 있더라도 에이전트가 규칙을 따르게 하세요.
13:22
이제 서류 캐비닛뿐만 아니라 방 전체가 잠겼습니다.
13:25
제어 평면 세 번째 단계, 승인 절차, 종량제 라이선스 경계, 그리고 데이터 정책입니다.
13:30
소스 범위를 지정하고 게으른 상속을 제거했습니다.
13:32
좋습니다.
13:33
이제 정문을 차단하여 무분별한 사용자가 함부로 액세스 권한을 가진 쉐도우 에이전트를 만들지 못하게 하세요.
13:38
누구나 에이전트를 만들 수 있다면 거버넌스는 무질서한 혼돈에 빠집니다.
13:42
해결책은 지루하지만 매우 효과적입니다.
13:44
운전 중에는 풀 수 없는 안전벨트처럼 작동하는 승인 절차, 라이선스 경계, 데이터 정책이 필요합니다.
13:50
에이전트 생성을 위한 승인 워크플로우부터 시작하세요.
13:55
지정된 승인자에게 전달되어야 합니다.
13:57
보안, 규정 준수, 그리고 해당 도메인을 제대로 이해하는 비즈니스 담당자를 생각하세요.
14:01
명명 규칙, 목적 기술서, 명시된 소유자, 지원 연락처, 만료일을 강제하세요.
14:06
소유자가 없으면 승인도 없습니다.
14:08
목적이 없으면 승인도 없습니다.
14:09
이게 지나치게 깐깐하게 들린다면 축하합니다.
14:11
드디어 거버넌스를 제대로 수행하고 계시네요.
14:14
신청 양식을 표준화하세요.
14:15
대상 독자, 제공할 비즈니스 기능, 라이브러리 수준의 정확한 URL 기반 지식 소스,
14:21
네이블 기대치, 풀백 동작, 범위 외 권한 제한, 사용할 서비스 아이디를 요구하세요.
14:28
인사 Q&A, 정책 브라우저, IT 기술 자료 등 사전 승인된 템플릿 중에서 선택하게 하세요.
14:34
즉흥적 인대응 대신 제약된 기본 설정을 상속받도록 하는 것입니다.
14:37
이제 라이선스 경계입니다.
14:38
사용자 기반 마이크로소프트 365 코파일럿 방식과
14:41
시어포인트 종량제 방식 중 하나를 선택해야 합니다.
14:44
진실 2호, 라이선스는 예산 항목이 아닙니다.
14:46
그것은 통제 수단입니다.
14:48
사용자 기반 코파일럿은 라이선스가 있는 사용자만 에이전트 기능을 사용할 수 있어
14:51
무분별한 확장을 자연스럽게 제한합니다.
14:53
종량제, 페이에이에스 유고를 사용하면 테넌트나 환경 수준에서 소비를 활성화하고
14:57
비용을 중앙에서 관리할 수 있는데
14:58
유연하지만 부주의하면 과도한 지출로 이어질 수 있습니다.
15:00
그래서 울타리를 쳐야 합니다.
15:02
파일럿과 운영 환경을 분리하고
15:03
재무부서가 비용을 확인할 수 있는 곳에서만 종량제를 활성화하세요.
15:07
비용 알림을 설정하여 파일럿 프로젝트가
15:09
클라우드 요금 폭탄으로 이어지지 않도록 하세요.
15:11
승인 정책에 라이선스 선택 사항을 포함해야 합니다.
15:14
종량제 라면 비용 센터, 결제 책임자, 예상 사용량 프로필을 요구하세요.
15:20
사용자 기반이라면 라이선스 사용자 명단과 오프보딩 계획을 요구하세요.
15:24
까다롭게 구는 게 아닙니다.
15:26
켜져 있는 줄 몰랐어요.
15:27
라는 상황을 방지하는 것입니다.
15:29
그 다음은 데이터 정책입니다.
15:30
에이전트가 금지된 커넥터에서 데이터를 마구잡이로 가져가지 못하게 하는 규칙이죠.
15:34
파워 플랫폼 테넌트 수준 데이터 정책을 사용하여
15:37
시어포인트와 동일한 데이터 그룹 내에서 허용되는 커넥터를 제한하세요.
15:40
규제 대상 에이전트는 마이크로소프트 365와 승인된 내부 API만 포함된 제한적 그룹에 둡니다.
15:45
이미 웹, 소비자 서비스, 섀도우 세스는 허용되지 않습니다.
15:49
통합이 필요하면 검토를 거쳐 엔터프라이즈 커넥터를 받고 허용 목록에 등록해야 합니다.
15:53
네, 시간이 걸리는 일입니다.
15:55
그게 바로 정책을 준수하는 과정입니다.
15:57
데이터 정책과 퍼뷰를 연동하세요.
15:59
퍼뷰를 사용하여 데이터 경계, 민감한 네이블이 지정된 콘텐츠의 위치,
16:04
허용되지 않는 데이터 유출 경로를 정의하고 그룹 간 연결 시도를 감시하세요.
16:08
차선과 안전지대를 만드는 과정입니다.
16:11
에이전트는 차선 안에서 빠르게 달릴 수 있습니다.
16:13
중앙 분리대를 넘어 공용 엔드포인트라는 맞은편 교통 흐름으로 뛰어들 수는 없습니다.
16:17
사전 승인된 소스를 포함한 에이전트 템플릿을 구현하세요.
16:19
다들 건너 뛰었다가 나중에 후회하는 부분입니다.
16:22
템플릿에는 일반 지식 비활성화, 신뢰할 수 없는 데이터 차단,
16:26
라이브러리 수준 소스, 필수 메타 데이터 필터,
16:28
올바른 서비스 아이디가 포함됩니다.
16:30
HR 정책 템플릿을 승인하면 올바른 기본값으로 배포된다는 것을 알 수 있습니다.
16:34
빈칸을 채우도록 만드세요. 그들이 굳이 잘못된 방식으로 바퀴를 다시 발명하게 하지 마세요.
16:39
테스트를 위해 관리되지 않는 사이트의 파일럿을 방치하거나,
16:42
비용 태그나 알림 없이 종량제를 켜거나,
16:44
아무에게나 메이커 역할을 부여하는 실수를 멈춰야 합니다.
16:47
또한, 에이전트가 답을 찾지 못할 때 일반 지식을 기본값으로 사용하게 하지 마세요.
16:52
그렇게 하면 그럴듯한 출처로 포장된 당당한 헛소리를 보게 될 겁니다.
16:55
최종 절차, 템플릿을 통한 요청, 보안 부서 검토,
16:59
세세 규정 준수 책임자 3인 승인,
17:01
비용 제어가 포함된 라이선스 선택,
17:03
제한된 데이터 그룹의 바인딩,
17:05
퍼뷰 경계 확인,
17:06
만료 기한과 함께 승인하고,
17:08
90일 단위 갱신 일정 수립,
17:09
갱신하지 않으면 자동 비활성화,
17:11
에이전트는 영원하지 않으며,
17:13
그 사용 사례 또한 그렇습니다.
17:15
제어 평면 4, 에이전트를 실제로 차단하는 DLP,
17:19
강력한 퍼뷰 패턴,
17:20
실시간 시행 없이는 에이전트는 고속 데이터 전달자에 불과합니다.
17:23
브레이크가 필요합니다.
17:25
단순 경고에 그치지 않고,
17:26
차단 및 알림을 수행하며,
17:27
감사자가 만족할 만한 기록을 남기는 퍼뷰 DLP 패턴을 도입하십시오.
17:30
왜 중요할까요?
17:31
에이전트는 콘텐츠를 단순히 보기만 하는 것이 아니라,
17:33
처리하기 때문입니다.
17:34
사람에게는 열람이 허용될 수 있습니다.
17:36
자동화된 처리는 차원이 다른 위험 요소입니다.
17:39
해결책은 에이전트 컨텍스트에 대해,
17:41
민감도 및 패턴 탐지를 명시적인 작업 차단과 결합하는 것입니다.
17:44
핵심은 다음과 같습니다.
17:45
에이전트의 데이터를 공급하는 셰어포인트 위치를 대상으로 정책을 구축하고,
17:49
민감도 레이블 및 민감정보 유형을 매칭하며,
17:51
신뢰도가 임계값에 도달할 경우,
17:53
에이전트의 처리, 공유, 다운로드를 차단하도록 설정을 구성하십시오.
17:56
네, 바로 신뢰도 임계값입니다.
17:58
그저 장식처럼 다루지 마십시오.
18:00
일반 PII와 같이 노이즈가 많은 패턴은 신뢰도를 높이고,
18:03
여러 증거 항목이 일치하도록 요구하십시오.
18:05
핵심 자산, 영업 비밀,
18:07
직원 아이디 위 정확한 데이터 일치,
18:09
EDM, 건은 높은 심각도를 적용해 즉시 차단하십시오.
18:12
강력한 패턴, 허용 목록에 없는 한,
18:15
에이전트 차단에 맵핑된 민감도 레이블,
18:18
금융 아이디, 정보식별자,
18:21
보건 관련 용어 등 민감정보 유형은 더 높은 신뢰도로 조정하십시오.
18:25
실제 식별자, 직원 번호, 고객 아이디에 대한 정확한 데이터 일치,
18:29
EDM를 사용하여 오탄으로 인한 혼란을 방지하십시오.
18:32
독점 프로젝트 코드명을 위한 키워드 사전,
18:35
낮은 볼륨, 높은 신호, 중요한 조치,
18:37
에이전트에 대해 재정의가 비활성화된 차단 설정,
18:40
사람은 정당성을 입증할 수 있지만 에이전트는 그렇지 못합니다.
18:42
기계는 비즈니스 맥락을 이해하지 못하며 그저 트리거에 반응할 뿐입니다.
18:45
에이전트 워크플로우가 트리거될 때 파일을 격리하거나 다운로드를 제한하십시오.
18:48
에이전트가 파일을 가져올 수 없으면 그 파일로 환각을 일으킬 수도 없습니다.
18:51
사이트 라이브러리 레이블, 트리거 패턴, 호출 에이전트 식별자 등 풍부한 컨텍스트와 함께 시콥세의 알림을 보내십시오.
18:56
사용자가 제어 장치를 우회하지 않도록 노이즈를 줄이십시오.
18:59
비운영 사이트에서 시뮬레이션 모드로 시작하십시오.
19:02
알림이 현실을 정확히 반영할 때까지 인계값을 조정하십시오.
19:05
먼저 에이전트 라이브러리에 영격하게 범위를 지정하고 신호가 명확해진 후에 확장하십시오.
19:09
레이블과 민감정보 유형을 조합한 다중조건, 즉 하나의 문에 두 개의 잠금장치를 사용하십시오.
19:13
사용자 메시지는 단순한 친절이 아닙니다.
19:15
규정 준수와 우회 경로를 가르는 결정적 차이입니다.
19:17
명확한 오류문구를 작성하십시오.
19:19
이 에이전트는 기밀 HR 콘텐츠를 처리할 권한이 없습니다.
19:22
HR 에이전트에게 문에하거나 정해진 절차를 통해 접근 권한을 요청하십시오.
19:25
사용자에게 벽이 아닌 올바른 문을 안내해주는 것입니다.
19:28
차단했다고만 하면 사용자는 데이터를 팀즈에 붙여 넣을 겁니다.
19:31
그건 당신 잘못이죠.
19:32
흔한 실수들입니다.
19:33
쉐어포인트 정책이 시끄러워 DLP 범위를 익스체인지와 팀즈로만 제한하는 경우죠.
19:37
시끄러웠던 이유는 당신이 조정하지 않았기 때문입니다.
19:39
성능 때문에 쉐어포인트를 제외하는 것도 마찬가지고요.
19:41
무엇의 성능을 말하는 건가요?
19:42
당신의 다음 사고 대응 성능인가요?
19:44
마지막으로 EDM을 무시하고 일반적인 PI 유형에만 의존하는 것입니다.
19:46
당신은 정확한 식별자를 보유하고 있습니다.
19:48
그걸 사용하세요.
19:49
리트머스 시험지입니다.
19:51
범위밖에 에이전트가 기밀 라벨이 지정된 파일이 필요한 질문에 답하려 합니다.
19:55
결과는 즉시 차단, 안내 메시지, 그리고 파이프라인의 고위험 경고여야 합니다.
20:00
만약 그 대신 자신 있는 답변을 받는다면 당신의 DLP는 장식품일 뿐입니다.
20:03
표지판이 아니라 실질적인 방어수단으로 만드세요.