교육과학기술부 각 기 웹사이트

개인정보 노출방지 가이드라인(개정 )

2008. 3.

교육과학기술부

가이드라인 개정 에 하여

본 개인정보 노출방지 가이드라인 (개정 )은 2007년

4월 행정자치부 ( 행정안 부 )에서 기배포한 “공공기

홈페이지 개인정보 노출방지 가이드라인”에 아래의 사항

이 추가된 개 정 입니다 .

- 구 을 통한 개인정보 노출 시 구 자동 삭제 시스

템 이용 방법 세부 차 (19～ 22Page)

우리부에서는 행정안 부에서 배포한 자료에 아래의 사항

을 추가하여 「교육과학기술부 웹사이트 개인정보 노출

방지 가이드라인」을 배포합니다 .

- “홈페이지 게시 의 제한 본인확인제 “ 와 “학교

홈페이지 구축 운 지침 ”에 한 안내 (38~ 39P age)

본 가이드라인 (개정 )이 우리부 각 기 의 웹사이

트 개인정보 노출 방에 좋은 길잡이가 되길 바랍니다 .

※ 원본자료 제공 : “공공기 웹사이트 개인정보 노출방지 가이드라인”(행정안 부 개인정보보호 )

목 차

Ⅰ. 개요 ·········································································1

Ⅱ. 개인정보노출 유형 유형별 조치방법 ······ 3

1. 웹페이지 노출 유형 ······························································3

2. 첨부 일 노출 유형 ·······························································9

3. 소스코드 노출 유형 ·······························································15

4. 외부 검색엔진 노출 유형 ·····················································18

Ⅲ. 개인정보노출 취약 검ㆍ조치방법 ··········26

1. 디 토리 리스 ·····································································27

2. 일 다운로드 ·········································································29

3. 일 업로드 ·············································································32

4. 크로스 사이트 스크립트(XSS) ·············································33

5. SQL Injection ··········································································34

6. 쿠키 암호화 ·············································································35

7. 근통제 ···················································································36

Ⅳ. 학교홈페이지 구축 운 시 유의사항 ···········38

1. 학교홈페이지 구축 운 지침 ···············································38

2. 홈페이지 게시 의 제한 본인확인제 ·····························38

Ⅴ. 맺음말 ·····································································40

【첨부】 학교홈페이지 구축 운 지침

1

교육과학기술부 웹사이트 개인정보노출 방지 가이드 라인

Ⅰ 개 요

□ 개인정보노출이란 무엇인가요?

홈페이지를 통한 개인정보노출이란, 일반 인터넷 이용자가 해킹 등

특별한 방법을 이용하지 않고 정상 으로 인터넷을 이용하면서 타인의 개인

정보를 취득할 수 있도록 방치되어 있는 것을 말합니다.

□ 개인정보노출이 왜 문제가 되나요?

홈페이지에 개인정보가 노출되는 경우, 악의 인 목 을 가진 사람이 이 개인

정보를 이용하여 스팸 발송 등으로 라이버시를 침해할 수 있을 뿐 아니라,

명의도용 등을 통해 경제 인 손실을 가져올 수 있습니다. 더구나 정상 인

인터넷 이용만으로도 개인정보를 쉽게 취득할 수 있어 개인정보 침해사고의

발생 가능성이 매우 높습니다.

□ 침해사고 험이 높은 개인정보는 어떤 것인가요?

개인정보란 “생존하는 개인을 식별할 수 있는 일체의 정보”를 의미하며,

그 에서 라이버시 침해사고 가능성이 있는 개인정보는 주민등록번호ㆍ

신용카드번호ㆍ은행계좌번호ㆍ법인등록번호ㆍ핸드폰번호ㆍ이메일주소 등이

있습니다. 그 에서 주민등록번호는 개인을 식별할 수 있는 인

개인정보로서 개인의 경제 인 피해를 수 있는 가장 요한 개인정보

입니다.

2

□ 개인정보노출을 방지하기 해서는 어디를 리해야 하나요?

개인정보가 노출되어 이용자들이 쉽게 개인정보를 취득할 수 있는 곳은

홈페이지의 모든 콘텐츠입니다. 즉, 일반 웹페이지에서부터 게시 과 첨부 일,

각 페이지의 소스코드 등은 일반 이용자들도 간단한 방법으로 개인정보를

얻을 수 있으므로 노출이 발생하지 않도록 지속 인 리가 필요합니다.

뿐만 아니라, 이 콘텐츠들은 언제든지 구 과 같은 외부 검색엔진에

의해 수집되어 정보가 장될 수 있으므로, 리자는 자신이 리하고 있는

홈페이지에 있는 개인정보가 외부 검색엔진에 장되어 있는지를 지속 으로

확인하고 리하여야 합니다.

3

Ⅱ 개인정보노출 유형 및 유형별 조치 방법

홈페이지에서 개인정보가 노출되는 원인은 크게 웹페이지, 첨부 일,

소스코드, 외부 검색엔진(구 등) 등 4가지로 나 수 있습니다. 한 각

원인별로 다양한 유형의 개인정보노출이 발생할 수 있습니다.

따라서 개인정보보호담당자는 리하는 홈페이지에서 발생할 수 있는

모든 유형의 개인정보 노출에 해서 검하여야 합니다. 개인정보노출

유형 그에 따른 조치방법을 설명하면 다음과 같습니다.

1. 웹페이지 노출 유형

가. 공지사항에 개인정보가 포함된 경우

<공 사항에 개 정보가 포함된 화면>

1) 유형 설명

이것은 해당 게시물 담당자의 부주의에 의해 개인정보가 포함된 콘텐츠를

그 로 공지한 경우입니다.

2) 조치 방법

리자는 해당 페이지를 즉시 삭제하거나 해당 개인정보 일부를 별표(*)

처리 하는 등의 조치를 취해야 합니다.

4

나. 민원인이 게재한 에 개인정보가 포함된 경우

<민원 게 한 글에 개 정보가 포함된 화면>

1) 유형 설명

이것은 해당 민원인의 부주의 는 신속한 민원처리를 해 의도 으로

개인정보가 포함된 콘텐츠를 그 로 게재한 경우입니다.

2) 조치 방법

리자는 민원인의 동의를 거쳐 해당 페이지를 즉시 삭제하거나 해당

개인정보 일부를 별표(*)처리 하는 등의 조치를 취해야 합니다.

5

다. 휴면홈페이지에 개인정보가 노출되어 있는 경우

<휴면사 트에 개 정보가 포함된 화면>

1) 유형 설명

휴면홈페이지란 장기간 동안 속자가 없는 홈페이지 는 정상 인

운 ㆍ 리가 이루어지지 않고 방치된 홈페이지를 말합니다. 표 인 로

다음을 들 수 있습니다.

① 정보화사업 추진과정에서 테스트용도로 개설 후, 사업 종결 후에도

방치된 임시 홈페이지

② 기 , 부서의 新홈페이지 구축 후 방치된 홈페이지

③ 타 유사홈페이지로 통합 후 방치된 홈페이지

④ 개편, 소멸, 청산된 조직․기업․ 의회 등의 홈페이지

⑤ 종결된 업무 는 연구개발사업 홈페이지

⑥ 폐회된 워크샵, 컨퍼런스 등 행사 련 홈페이지

⑦ 소유자의 직, 퇴사 등으로 리부재 상태인 개인 홈페이지

⑧ 다수 홈페이지가 운 되는 동일 서버에서 방치되고 있는 미활용 홈페이지

⑨ 기타 속이 없거나 활용도가 은 홈페이지

6

휴면홈페이지를 통한 개인정보 노출이란, 휴먼홈페이지가 개인정보를

노출한 채로 방치되어 휴먼홈페이지 주소를 알면 개인정보를 얻을 수 있는

경우를 말합니다. 이 유형은 리자가 인지하지 못하는 범 에서 발생하는

개인정보노출이므로 노출이 장기간 발생할 수 있는 험이 있습니다.

특히 구 과 같은 외부 검색엔진들은 이 에 수집했던 웹페이지 주소

정보를 장하고 있으므로 이 주소정보를 이용하여 지속 으로 개인정보

노출이 일어날 수 있습니다.

2) 조치 방법

리자는 리하는 웹서버 내에 잔존하는 휴면 홈페이지를 모두 삭제하

거나 휴면 홈페이지의 개인정보노출 여부를 일제 검하여 삭제처리 하는

등의 리를 하여야 합니다.

7

라. 답 에 개인정보가 포함된 경우

<답글 성 시 개 정보가 포함된 화면>

1) 유형 설명

이것은 개인정보가 포함된 기작성 에 담당자가 답변을 하는 과정에서

기작성 에 포함된 개인정보가 그 로 답변에 첨부되어 개인정보가

노출되는 경우입니다.

2) 조치 방법

리자는 해당 페이지에 포함된 개인정보를 즉시 삭제하는 등의 조치를

취해야 합니다.

8

마. 근제한 페이지( 리자화면/입력ㆍ수정화면 등)에 개인정보가

포함된 경우

< 리 화면에 개 정보노출> <수정/편 화면에 개 정보노출>

1) 유형 설명

이것은 게시물을 수정/편집하는 화면을 권한이 없는 이용자가 근할 수

있도록 홈페이지가 잘못 설계되어 발생하는 경우를 말합니다.

원래 홈페이지는 게시물의 수정/편집을 해당 게시자나 홈페이지 리자 등

근권한을 가진 이용자만이 할 수 있도록 보안기능을 고려하여 설계하여야

합니다. 그러나 각 페이지별로 근권한 인증 등의 차가 제 로

구 되지 않으면 이와 같은 노출이 발생할 수 있습니다.

2) 조치 방법

리자는 해당 홈페이지에 한 보안기능이 어떻게 설계 되었는지를

악하여 각 페이지별로 근권한에 따른 인증 차를 수하도록 수정

하여야 합니다.

9

2. 첨부 일 노출 유형

홈페이지 게시 에는 엑셀, 한 , 워포인트, PDF, ZIP 등의 첨부 일이

존재할 수 있으며, 이 일들에서 개인정보가 노출될 수 있으므로 이에 한

검 조치가 필요합니다. 첨부 일에서 발생하는 개인정보노출 유형과

조치 사항은 다음과 같습니다.

가. 일반 인 경우

<한글 파 에 개 정보가 포함된 화면>

1) 유형 설명

홈페이지의 게시 에 게재된 첨부 일에 개인정보가 포함되어 있는

경우입니다. 특히 가장 일반 인 경우는 한 과 같은 문서 일에 주민등록

번호 등이 포함되어, 첨부 일을 열었을 때 개인정보를 쉽게 확인할 수 있는

경우입니다.

2) 조치 방법

리자는 해당 일의 게시자에게 통보하여 게시 에서 해당 게시물을

삭제한 후, 개인정보를 제거한 일을 다시 게재하도록 조치하여야 합니다.

10

나. 엑셀 일의 다른 Sheet에 개인정보가 포함된 경우

<노출 견되 않는 Sheet> <노출 견되는 다른 Sheet>

1) 유형 설명

이것은 엑셀 일에서만 나타나는 유형으로 첨부 일을 열었을 때에는

보이지 않지만, 첨부 일 내의 다른 Sheet에는 개인정보를 포함하고 있어

발생하는 노출 유형입니다.

2) 조치 방법

리자는 해당 일의 게시자에게 통보하여 게시 에서 해당 게시물을

삭제한 후, 개인정보를 제거한 일을 다시 게재하도록 조치하여야 합니다.

한편 업무 담당자는 엑셀 일을 홈페이지에 등록할 경우 불필요한 sheet가

해당 일에 포함되지 않도록 미리 삭제한 후 게재하는 것이 바람직합니다.

11

다. 잘 보이지 않는 곳에 개인정보가 포함된 경우

<노출 보 않 > <최하단에서 노출 견됨>

1) 유형 설명

이것은 엑셀 일에서 주로 나타나는 유형으로 첨부 일을 열었을 때

바로 보이는 부분에서는 개인정보가 발견되지 않지만, 셀 최하단 는

최우측으로 이동하 을 때 개인정보가 발견되는 경우입니다.

2) 조치 방법

리자는 해당 일의 게시자에게 통보하여 게시 에서 해당 게시물을

삭제한 후, 개인정보를 제거한 일을 다시 게재하도록 조치하여야 합니다.

12

라. 개인정보를 숨김처리 하 지만 노출되는 경우

<개 정보를 숨김처리 한 경우> <개 정보 숨김 취소한 경우>

1) 유형 설명

이것은 엑셀 일에서 주로 나타나는 유형으로 첨부 일을 열었을 때

개인정보가 포함된 셀이 숨김처리가 되어 개인정보가 발견되지는 않지만,

숨김을 취소하면 개인정보가 발견되는 경우입니다.

한 숨김처리를 하면서 암호화를 하더라도 문서변환도구를 이용하면

쉽게 해당 내용을 볼 수 있으므로 유의하여야 합니다.

2) 조치 방법

리자는 해당 일의 게시자에게 통보하여 게시 에서 해당 게시물을

삭제한 후, 개인정보를 제거한 일을 다시 게재하도록 조치하여야 합니다.

13

마. 개인정보를 은폐하 지만 노출되는 경우

<개 정보를 폐한 화면> <개 정보가 검색된 화면>

1) 유형 설명

이것은 모든 첨부 일에서 나타날 수 있는 유형으로 일에 있는 개인

정보 일부를 은폐하기 해서 해당 개인정보 에 이미지 등을 덮어 워

보이지 않지만, 일 검색 기능을 이용하 을 때 개인정보가 발견되는

경우입니다. 를 들어, 주민등록번호가 일에 있는 경우, 13자리 숫자

7자리에 해 은폐처리를 하더라도 이 발견되는 7자리 숫자로 검색을

하면 13자리 주민등록번호를 모두 확인할 수 있습니다.

2) 조치 방법

리자는 해당 일의 게시자에게 통보하여 게시 에서 해당 게시물을

삭제한 후, 개인정보를 제거한 일을 다시 게재하도록 조치하여야 합니다.

14

바. 치환함수 등을 이용하 지만 노출되는 경우

< 환함수를 적용한 화면> <개 정보가 검색된 화면>

1) 유형 설명

이것은 엑셀 일에서 주로 나타나는 유형으로 개인정보가 포함된 셀에

LEFT 등의 치환함수를 용하여 *처리 등으로 개인정보가 은폐된 것처럼

보이게 하지만, 엑셀 일의 검색기능을 이용하면 개인정보가 발견되는

경우입니다. 특히 치환함수를 용하기 해서는 어딘가에 해당 개인정보가

숨김처리 되어 있어야 하므로「라」유형에 의한 노출 한 포함되어 있는

경우가 부분입니다.

2) 조치 방법

리자는 해당 일의 게시자에게 통보하여 게시 에서 해당 게시물을

삭제한 후, 개인정보를 제거한 일을 다시 게재하도록 조치하여야 합니다.

15

3. 소스코드 노출 유형

모든 웹페이지는 기본 으로 소스코드가 공개되어 있습니다. 해당 웹페이지의

소스코드는 웹페이지 에 마우스를 놓고 오른쪽 버튼을 클릭하 을 때

나타나는 팝업 메뉴에서 선택하면 볼 수 있습니다. 이와 같은 소스코드에

의한 노출은 명의도용을 하려는 이용자가 게시 의 게재자의 정보가 소스

코드에 있는지 등을 확인하는 경향이 있다는 에서 개인정보 노출의

유형으로 볼 수 있습니다. 소스코드에서 발생하는 개인정보 노출 유형과

조치 방법은 다음과 같습니다.

가. 게시 소스코드에 개인정보가 포함된 경우

< 적 웹페 화면> <개 정보가 포함된 소스코드>

1) 유형 설명

이것은 웹페이지의 게시 소스코드에서 나타나는 유형입니다. 홈페이지

설계 시 게시물에 한 구분자로서 게시자의 개인정보를 이용하는 경우

소스코드에는 이 개인정보가 그 로 나타날 수 있습니다.

2) 조치 방법

홈페이지 설계단계에서 개인정보를 구분자로 사용하지 않도록 검토가

필요합니다. 가장 간단한 조치방법은 웹페이지를 구별하기 해 이용되는

개인정보를 해쉬함수 등을 이용하여 변환하여 용하는 것입니다.

16

나. 웹페이지 URL에 개인정보가 포함된 경우

<웹페 주소에 개 정보가 포함된 화면>

1) 유형 설명

이것은 웹페이지의 URL에서 주로 나타나는 유형으로, 홈페이지 설계 시

조직구성원 등의 소개 웹페이지나 개인홈페이지의 주소부여 체계에서

개인정보를 이용하는 경우에 발생할 수 있습니다.

2) 조치 방법

홈페이지 설계단계에서 개인정보를 구분자로 사용하지 않도록 검토가

필요합니다. 조치 방법으로는 해당 웹페이지와 련된 새로운 주소부여체계를

용할 수 있으며, 보다 간단한 조치방법으로는 웹페이지 URL에 이용되는

개인정보를 해쉬함수 등 함수를 이용하여 변환하여 용하면 됩니다.

17

다. 웹페이지 소스코드 일명에 개인정보가 포함된 경우

< 적 웹페 화면> <개 정보가 포함된 소스코드>

1) 유형 설명

이것은 웹페이지의 일명에 해당하는 소스코드에서 나타나는 유형입니다.

홈페이지 구축 시, 조직구성원의 이미지 일명으로 해당 개인의 개인정보를

이용하는 경우 소스코드에는 이 개인정보가 그 로 나타날 수 있습니다.

2) 조치 방법

해당 일의 이름을 모두 개인정보와 무 한 일명으로 변경합니다.

18

4. 외부 검색엔진 노출 유형

구 검색엔진은 세계 으로 가장 강력한 성능을 가진 검색엔진으로

명의도용 의도를 가진 이용자가 자주 이용하는 창구역할을 하고 있습니다.

따라서 홈페이지를 통한 개인정보 노출 방지를 해서는 홈페이지에서

노출된 개인정보를 구 검색엔진이 수집하 는지 지속 으로 악하고

검할 필요가 있습니다. 구 검색엔진을 통한 노출 유형과 조치 방법은

다음과 같습니다.

가. 일반 인 경우

< 글에 개 정보가 검색된 화면> <링크된 개 정보 노출화면>

1) 유형 설명

이것은 구 검색엔진을 통해 방문한 해당 웹페이지에 개인정보가 발견

되는 유형입니다. 최근 구 검색엔진은 주민등록번호 뒤의 7자리를 *로

치환하여 검색결과를 일부 제공하기도 하지만, 여 히 주민등록번호 13자리가

모두 검색결과로 제공되는 경우가 발생하고 있습니다. 따라서 이 유형은

검색결과의 *치환 여부와 계없이 검색 결과를 클릭하 을 때, 해당

웹페이지에 개인정보가 존재하는 경우를 말합니다.

19

2) 조치 방법

이러한 유형의 노출이 발견되면 먼 해당 웹페이지에 있는 내용

개인정보를 즉시 삭제하여야 합니다. 그 후에 검색엔진 배제표 이나 메타

태그를 용합니다. 검색엔진 배제표 을 용하기 해서는 다음과 같은

내용으로 된 robots.txt 일을 웹서버의 루트 디 토리에 장합니다.

User-Agent: *

Disallow:/

한 메타태그를 용하기 해서는 삭제하려는 웹페이지의 소스코드 일

(HTML 일)에 <META NAME = GOOGLEBOT" CONTENT= "NOINDEX,

NOFOLLOW">를 포함합니다.

이제 구 의 자동제외 시스템에 속하여 개인정보 노출이 발견된

웹페이지를 캐쉬에서 삭제 처리해달라고 요청합니다. 정상 인 로세스를

거칠 경우 삭제 처리는 요청 후 일주일 정도 소요됩니다.

가) 구 회원 가입 로그인

구 자동삭제 시스템 이용을 해서 먼 구 웹사이트에 가입 한 후

로그인합니다.

나) 구 자동삭제 시스템에 속

(1) 로그인 상태에서 다음과 같은 구 자동삭제 시스템에 방문합니다.

https://www.google.com/webmasters/tools/removals?hl=ko

20

(2) 기 화면에서 “Google 검색결과에서 시한이 지났거나 ”사용하지 않

는 링크“로서, 404- 일을 찾을 수 없음 오류에 해당되는 링크입니다”

를 선택하고 “다음” 버튼을 선택합니다.

<구 자동삭제 시스템 속 화면>

나) Google 검색결과에서 기한이 지난 링크제거

(1) “Google 웹 검색결과” 를 선택합니다.

(2) “웹페이지 는 이미지 URL”에 기 삭제한 홈페이지 URL 주소를 입

력하고 “요청 제출”을 클릭합니다.(이 때, 구 캐쉬 주소를 입력하면

삭제처리가 되지 않으므로 주의합니다.)

<Google 검색결과에서 기한이 지난 링크제거 화면>

다) 삭제 요청 처리 상태 확인

자동 삭제처리 시스템에서 “내 제거 요청”을 클릭하면 재 삭제 요청 정

보 처리 상태를 확인할 수 있습니다.

21

<삭제요청 처리 화면>

22

나. 구 DB에만 노출이 존재하는 경우

< 글에 개 정보가 검색된 화면> <삭제된 해당 웹페 화면>

1) 유형 설명

이것은 개인정보가 포함되어 있는 웹페이지는 삭제되었으나, 구 검색

엔진에 장되어 검색 시 개인정보가 발견되는 유형입니다.

2) 조치 방법

검색엔진 배제표 이나 메타 태그를 용합니다. 구체 인 조치 방법은

「가」의 경우와 같습니다. (19페이지 참고)

이제 구 의 자동삭제 시스템에 속하여 개인정보 노출이 발견된 웹페이

지를 캐쉬에서 삭제 처리해달라고 요청하는데, 그 세부 차는 p19 ~ 21의

구 자동삭제 시스템 이용 차와 같습니다. 구 자동삭제 시스템을 이용

하지 않고, 구 웹사이트 리자에게 이메일을 통해 삭제를 요청하는 정

상 인 로세스를 통하면 삭제 처리는 요청 후 6주 ~ 8주가 소요됩니다.

23

다. 구 의 인증우회방식에 의한 개인정보 노출의 경우

1) 인증 우회 개요

일반 으로 웹 서버는 리자 페이지와 같이 근제한이 필요한 일부 역에

해서 인증 등의 차를 통하여 제한 으로 근을 허용하도록 구성되어

있습니다.

그러나 웹 서버의 근제한 기능이 불완 하게 구성되는 경우, 구 과

같은 검색엔진은 인증 차를 거치지 않고 우회하여 인증이 필요한 페이지에

근하고, 근하여 획득한 정보를 검색엔진 DB에 장함으로써 일반

인터넷 이용자에게 해당 정보가 제공됩니다. 특히 웹 서버내의 각 리자

페이지들은 서로 링크되어 있어서 하나의 리자 페이지에만 속하면

모든 리자페이지에 근할 수 있으므로 인증이 필요한 역 체에

완 한 인증 차를 요구하도록 홈페이지를 구 하여야 합니다.

2) 검색엔진의 인증우회 방법

구 과 같은 검색엔진은 해킹과 같은 비정상방법이 아닌 정상 인

웹서버 근방법에 의해서 인증을 우회할 수 있습니다.

이 때 구 과 같은 검색엔진이 정상 인 근에 의해 인증을 우회하는

방법은 ① 리자 페이지 역의 URL 자동 근 ②웹보안 취약 을 통한 근 등

두 가지 경우가 있습니다.

① 리자 페이지 역의 URL 자동 근

이 경우는 구 과 같은 검색엔진은 웹 서버에 근할 때, 일반 이용자들이

웹 라우 를 이용하는 것과는 달리 Socket을 통해서 웹 서버에 근하기

때문에 발생합니다.

먼 구 과 같은 검색엔진은 웹 서버 내의 정보 검색 시 재 근한

페이지의 링크 추 , 과거에 근했던 URL 리스트를 이용한 검색, URL에

포함된 라미터값 자동 계산 등의 다양한 방법을 이용하여 검색할 수

24

있습니다. 이러한 검색과정에서 리자 페이지에 해당하는 특정 URL이

검색되면, 웹 라우 를 이용하여 URL에 근하는 경우에는 웹 서버가

근을 요청한 웹 라우 의 아이디에 한 세션 체크 등의 근 유효성을

검사하지만, 검색엔진의 Socket 통신을 이용하는 경우 이러한 유효성 검사를

생략하므로 해당 웹 페이지에 바로 근할 수 있습니다.

② 웹보안 취약 을 통한 근

이 경우는 웹 서버가 디 토리 리스 과 같은 보안 취약 을 갖는 경우에

발생합니다. 즉, 구 과 같은 검색엔진은 URL 정보 획득 과정에서 URL

뒤에 / 만을 붙여서 체크할 수 있는 디 토리 리스 취약 페이지 정보를

획득하게 되고, 이 취약 에 노출된 디 토리가 리자 페이지와 같이

인증을 필요로 하는 페이지인 경우 인증을 거치지 않고 근할 수 있습니다.

3) 검색엔진의 인증우회 방지방법

① 리자 페이지 역의 URL 자동 근

검색엔진의 인증우회는 근본 으로 인증이 필요한 페이지 역 체에

해 인증 요구 차가 완 히 구 되지 않아서 발생합니다. 따라서 리자는

인증을 필요로 하는 모든 역에 속한 모든 페이지 근 시 인증 차를

거치도록 설계하여야 합니다.

를 들어 JAVA로 구 된 웹페이지의 경우, 각 웹 페이지 상단에 다음과

같은 소스 코드를 삽입합니다.

<jsp:include flush="true" page="session_check.jsp" />

여기서 session_check.jsp 일은 인증을 처리하는 일로 실제 용

코드에는 이 일이 있는 체 URL을 습니다. 이 때 session_check.jsp

일의 는 다음과 같습니다.

25

<%

 // 세션 체크

 SPInfoBean bean = (SPInfoBean) session.getAttribute("user.login");

 if (bean == null) {

%>

  <script>

   alert('로그인 정보가 없습니다.');

   this.location = "index.jsp";

  </script>

<%

 }

%>

② 웹보안 취약 을 통한 근

웹보안 취약 을 통한 근에 한 인증우회를 방지하기 해서는 웹

서버 내의 모든 디 토리에 한 디 토리 리스 취약 을 제거하여야

합니다. 이에 한 조치방법은 본 가이드라인 25페이지에서 자세히 설명하고

있습니다.

26

Ⅲ 개인정보노출 취약점 점검 및 조치 방법

홈페이지를 통한 개인정보 노출이 발생하는 원인은 크게 리 인 원인과

기술 인 원인으로 나 수 있습니다. 리 인 원인이란 홈페이지 리자와

이용자의 개인정보에 한 인식 부족이나 리 소홀 때문에 발생하는

원인을 말하며, 기술 인 원인은 홈페이지 설계 구축 단계에서 개인정보

노출이나 보안 취약 을 고려하지 않아서 발생하는 원인을 말합니다.

그 에서 개인정보노출에 직 인 원인이 되는 것은 리 인 원인과

기술 인 원인 개인정보노출을 고려하지 않아서 발생하는 원인들인데,

이 원인들로 인한 개인정보노출 유형 처 방안은 앞에서 설명한 바

있습니다.

한편, 기술 인 원인 에서 보안 취약 을 고려하지 않고 설계ㆍ구축된

홈페이지는 개인정보노출의 간 인 원인을 제공합니다. 를 들어,

웹 서버의 디 토리 일 목록을 보여주는 디 토리 인덱싱과 같은

보안 취약 이 존재하는 경우, 구 검색엔진은 디 토리 인덱싱 웹페이지를

검색에 활용하므로 웹 서버 내에 존재하는 개인정보가 그 로 노출될

험이 있습니다.

이 장에서는 개인정보노출에 한 간 인 원인이 되는 웹서버의

보안취약 을 리자가 자체 으로 검할 수 있는 기본 이며 리 알려진

방법과 발견 시 조치방법을 설명합니다. 특히 여기서는 리 웹서버의

개인정보노출과 련된 보안취약 뿐만 아니라, 보안취약 이 발생한

웹페이지가 구 검색DB에 장되어 있는지 여부를 검하는 방법도

제공합니다.

27

개요 인터넷 이용자에게 웹 서버 내 모든 디 토리 일 목록을 보여주고, 일의

열람 장도 가능하게 하는 취약

검범 검 상 홈페이지에 디 토리 리스 취약 이 존재하는지 여부를 검하고,

디 토리 리스 취약 페이지가 구 엔진에 장되었지는 여부를 검한다.

검

방

법

구 을

통한

검

방법

¡ 구 사이트에 속한다.

¡ 고 검색으로 이동한다.

¡ 도메인 설정 란에는 해당 사이트 주소를 입력하고, 검색창에는 다음을 입력

하여 디 토리 목록이 장된 페이지를 찾는다.

­ intitle:index.of "parent directory"

­ intitle:index.of name size

¡ 검색 결과를 바탕으로 해당 사이트의 디 토리 노출을 확인한다.

직

검

방법

¡ 해당 웹 사이트의 하 디 토리 정보를 사 에 모두 확인한다.

¡ 웹 루트의 모든 하 디 토리에 해서 웹 라우 에 해당 주소를 입력

해서 디 토리 노출 여부를 검한다.

) http://www.sample.go.kr/ 이란 웹 서버의 웹 루트 에 “file”이란 디 토

리가 있다면 웹 라우 의 URL 주소 입력란에

http://www.sample.go.kr/file/ 이라고 입력한다. 이 때 “file” 디 토리 하

내용이 모두 화면에 출력된다면 디 토리 리스 취약 이 존재하는

것이다.(반드시 맨 끝의 ‘/’ 까지 입력)

¡ 모든 디 토리에 해 디 토리 리스 취약 존재 여부를 확인한다.

조치

방법

구

캐쉬에

노출된

경우

¡ 개인정보 취약 페이지가 구 에 노출된 경우에는 먼 홈페이지에도

개인정보 취약 노출이 있는지 여부를 확인하여 홈페이지의 개인정보

취약 을 제거 한 후, 구 검색 사이트에 해당 캐쉬에 해 삭제를 요청하는

이메일을 발송한다.

¡ 개인정보의 노출 정도가 심각하여 긴 하게 노출을 방지하고자 한다면,

구 의 자동 URL 삭제 시스템을 이용하여, URL이 검색되지 않도록 한다.

1. 디 토리 리스 취약

28

※구 자동 URL 삭제 시스템:

http://services.google.com:8882/urlconsole/controller?cmd=reload&lastcmd=login

직

검 시

노출의

경우

( 도우)

¡ [제어 ]→[ 리도구]의 [인터넷 서비스 리자](혹은 [인터넷 정보 서비스])

메뉴에서 [기본 웹 사이트]의 마우스 오른쪽 클릭, ‘속성’ 부분을 보면 ‘기본

웹 사이트 등록 정보’가 나온다.

¡ ‘기본 웹 사이트 등록 정보’에서 ‘홈 디 토리’ 부분을 클릭한 후 ‘디 토리

검색(B)' 부분의 체크를 해지한다.

직

검 시

노출의

경우

(리 스

/유닉스)

¡ 서버에서 “httpd.conf” 라는 일을 찾는다.

¡ 일 내용 Options 항목 뒤에 Indexes 라는 단어를 지우고 일을 장한다.

이 때, Options 는 디 토리 별로 설정할 수 있게 되어 있으므로 모든

디 토리에 해서 Options 항목을 제거한다.

¡ 설정을 용하기 해 웹 서버 데몬을 다시 띄워 다.

29

개요 게시 등에 장된 자료에 해 치 지정에 한 제한을 부여하지 않음으로써 웹

서버 내의 비공개 자료를 다운로드 받을 수 있도록 하는 취약

검

범

검 상이 되는 홈페이지에 일 다운로드 기능이 존재하는지 여부를 검하고,

일 다운로드 스크립트 이용 여부를 확인한 후, 다운로드 스크립트의 매개변수를

변경하면서 주요 일 다운로드를 시도한다.

검

방법

¡ 게시 이 존재하는지, 그리고 그 게시 에 일 다운로드 기능이 있는지 검한다.

일 다운로드 기능이 존재하지 않으면 ‘ 일 다운로드’ 취약 은 존재하지 않는다.

¡ 일 다운로드 기능이 존재하는 경우, 일 다운로드 시의 URL 주소를 확인하여

일 다운로드 스크립트를 이용하는지 여부를 확인한다. 일 다운로드 URL

주소 확인은 첨부 일 하이퍼링크 부분에 마우스를 가져가 아래 상태표시 로

부터 링크를 확인하거나 팝업 메뉴의 ‘바로가기 복사(T)'를 클릭하고 메모장

등에서 ’붙여넣기‘ 함으로써 확인할 수 있다. 일 다운로드 스크립트를 이용하지

않으면 ‘ 일 다운로드’ 취약 은 존재하지 않는다.

<다운로드 스크립트를 사용하지 않는 경우의 >

http://servername.go.kr/test/download/공지사항1.hwp

<다운로드 스크립트를 사용하는 경우의 >

http://servername.go.kr/test/filedown.down?file=공지사항3.hwp&path=download

¡ 일 다운로드 스크립트를 이용하는 경우, 매개변수를 변경하면서 주요 일

다운로드를 시도한다. 이 때, 매개변수의 개수 경로를 는 형식이 조 씩

틀리므로 링크 주소에 따라 상 으로 매개변수 변경을 시도해야 한다.

① /etc/passwd 일 다운로드 시도

asp

게

시

<정상 인 링크>

http://servername.go.kr/pr/download.asp?filename=test.hwp

<다운로드 시도>

http://servername.go.kr/pr/download.asp?filename=/etc/passwd

2. 일 다운로드 취약

30

http://servername.go.kr/pr/download.asp?filename=../../../etc/passwd

등의 형태로 시도하되, 링크 ../의 개수를 1개부터 10개까지 차 증가시키면서

시도한다.

PHP

게

시

<정상 인 링크>

http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=test.hwp

<다운로드 시도>

http://servername.go.kr/includes/download.php?sub_path=../../../etc&filename=passwd

http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=../../../../../..

/etc/passwd

등의 형태로 시도하되, 의 두 가지 링크 각각에 해 ../의 개수를 1개부터

10개까지 차 증가시키면서 시도한다.

jsp

게

시

<정상 인 링크>

http://servername.go.kr/include/down.jsp?upfile=test.hwp&dir=/data

<다운로드 시도>

http://servername.go.kr/include/down.jsp?upfile=passwd&dir=/etc

http://servername.go.kr/include/down.jsp?upfile=passwd&dir=/data/../../../etc

등의 형태로 시도하되, 의 두 번째 링크에 해 ../의 개수를 1개부터 10개까지

차 증가시키면서 시도한다.

기타

게

시

<정상 인 링크>

http://servername.go.kr/servlet/Down?path=/DATA/docu/2006/10/10&name=test.hwp

<다운로드 시도>

http://servername.go.kr/servlet/Down?path=../../../../etc&name=passwd

http://servername.go.kr/servlet/Down?path=/DATA/../../../etc&name=passwd

등의 형태로 시도하되, 링크 ../의 개수를 1개부터 10개까지 차 증가시키면서

시도한다.

② download 일 다운로드 시도

ASP

게

시

<정상 인 링크>

http://servername.go.kr/pr/download.asp?filename=test.hwp

<다운로드 시도>

http://servername.go.kr/pr/download.asp?filename=../pr/download.asp

31

등의 형태로 시도하되, 링크 ../의 개수를 1개부터 10개까지 차 증가시키면서

시도한다.

PHP

게

시

<정상 인 링크>

http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=test.hwp

<다운로드 시도>

http://servername.go.kr/includes/download.php?sub_path=includes&filename=downloa

d.php

http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=../../../../../..

/includes/download.php

등의 형태로 시도하되, 의 두 번째 경우에 해서는 ../의 개수를 1개부터

10개까지 차 증가시키면서 시도한다.

jsp

게

시

<정상 인 링크>

http://servername.go.kr/include/down.jsp?upfile=test.hwp&dir=/data

<다운로드 시도>

http://servername.go.kr/include/down.jsp?upfile=down.jsp&dir=/include

등의 형태로 시도하되, 링크 ../의 개수를 1개부터 10개까지 차 증가시키면서

시도한다.

¡ 다운로드 시도가 성공하는 경우 직 웹 라우 화면에 내용이 뜨거나 ‘ 일

장’을 통해 장이 될 수 있다. 이 경우들은 모두 일 다운로드 취약 을

가지고 있는 경우이다.

조치

방법

첨부 일이 장되어 있는 특정 디 토리에 있는 일만을 다운 받을 수 있도록

하기 해 첨부 일을 다운받기 해 사용하는 다운로드 스크립트를 다음과 같은

방법으로 수정해야 한다.

¡ 다운받기 한 일 이름에 “..”, “/”, “\”와 같은 문자열이 존재하면 모두 필터링

한다. 이 부분은 웹 서버 설정으로 해결할 수 있는 것이 아니로 스크립트의

내용을 수정해야 한다.

¡ 스크립트 수정이 된 후에 다시 한번 취약 검 때와 같이 일 다운로드가

되는지 여부를 확인하는 시도를 통해 취약 이 여 히 존재하는지를 검한다.

32

개요 게시 에서 첨부 일을 업로드 하는 경우, 악성 실행 로그램을 업로드한 후에

홈페이지 속 방식으로 웹서버를 원격 제어할 수 있게 하는 취약

검범 검 상이 되는 홈페이지에 일 업로드 기능이 존재하는지 여부를 검하고,

특정 확장자를 가진 악성 일의 업로드를 시도한다.

검방법

¡ 게시 이 존재하는지, 그리고 그 게시 에 일 업로드 기능이 있는지

검한다. 일 업로드 기능이 존재하지 않으면 ‘ 일 업로드’ 취약 은

존재하지 않는다.

¡ 일 업로드 기능이 존재하는 모든 게시 에 해서, php, php3, asp, jsp,

cgi, inc, pl 등의 확장자를 가진 일 업로드를 시도한다. 일 업로드를

확인하 을 때, 실제 업로드가 되었다면 ‘ 일 업로드’ 취약 이 존재한다.

조치방법

게시 의 첨부 일 업로드를 처리하는 웹 소스코드에서 첨부 일의 확장자를

필터링하도록 처리한다.

¡ 게시 작성 후 업로드 버튼을 클릭할 때, 첨부 일을 확인하여 php, php3,

asp, jsp, cgi, inc, pl 등의 확장자를 갖는 일의 경우는 경고창을 띄워

업로드를 제한한다.

¡ 웹 소스 수정을 한 후에 다시 한 번 취약 검과 같은 시도를 통해

취약 이 여 히 존재하는지를 검한다.

3. 일 업로드 취약

33

개요

게시 에서 쓰기를 하는 경우, 입력 내용 실행코드인 스크립트의 태그에

한 필터링을 하지 않아서 악의 인 스크립트 등록을 통해 일반 이용자 PC로부터

개인정보인 쿠키 등을 유출할 수 있게 하는 취약

검범 검 상이 되는 홈페이지 게시 에 쓰기 기능이 존재하는지 여부를 검하고,

간단한 스크립트 문장을 입력하여 게시를 시도한다.

검방법

¡ 게시 , 의견쓰기, 게시마당, 민원신청, 여론마당 등에 해 일반 사용자들이

을 게시할 수 있는 기능이 있는지 검한다. 쓰기 기능이 없으면

‘XSS 취약 ’은 존재하지 않는다.

¡ 쓰기 기능이 있는 게시 에 해 본문에 다음과 같은 스크립트 문장을

입력하고 게시를 시도한다.

<script>alert('XSS 취약 존재‘);</script>

¡ 을 게시하는 에 스크립트 태그 사용에 한 ‘에러’나 ‘경고’ 메시지가

뜨면서 등록이 안된다면 ‘XSS 취약 ’이 존재하지 않는 것이다.

¡ 도우 경고창이 뜨지않고 본문에 스크립트 문장이 입력한 로

나오면 XSS 취약 이 존재하지 않는 것이다.

¡ 도우 경고창을 통해 'XSS 취약 존재‘ 나 “XSS&nbsp;취약 &nbsp;존재”와

같은 형태의 팝업창이 뜨면 ‘XSS 취약 ’이 존재하는 것이다.

조치방법

XSS 취약 은 웹 서버 설정으로는 조치할 수 없다. 쓰기가 가능한 게시

페이지에서 이용자가 스크립트를 입력할 수 없도록 다음과 같이 조치한다.

¡ 스크립트 문장에 존재할 수 있는 <, >, (, ), #, & 등의 메타 문자를

다른 문자로 변환하거나 게재 시 에서 스크립트가 있는 경우에는 게재를

차단한다.

¡ 웹 소스코드 수정이 된 후에 다시 한 번 XSS 취약 이 있는 지 검한다.

4. 크로스 사이트 스크립트(XSS)

34

개요

웹 라우 주소창, 이용자 ID/패스워드 입력화면 등에서 데이터베이스 SQL문에

이용되는 문자기호 입력을 필터링하지 않은 경우, 이용자가 SQL 조작에 의한

입력을 통해 데이터베이스에 인증 차 없이 근하여 자료를 무단 유출하거나

변조할 수 있는 취약

검범 웹사이트의 기본 인 사용자 인증창 우회 SQL Injection 취약 검 방법을

이용하여 취약 존재 가능성을 검한다.

검방법

¡ 홈페이지 리자 로그인 페이지로 이동한다.

¡ 리자 아이디와 패스워드에 아래 문자열을 입력하여 결과를 확인한다.

① ‘or 1=1;- -

② ‘ ’ or 1=1- -

③ "or 1=1 --

④ or 1=1--

⑤ 'or 'a'='a

⑥ " or "a"="a

⑦ ')or('a'='a

⑧ sql' or 1=1- -

⑨ sql" or 1=1--

⑩ + or 1=1- -

⑪ ';- -

¡ 인증 실패 메시지가 나타날 경우, ‘SQL Injection 취약성’은 존재하지 않는다.

¡ 로그인 될 경우, SQL Injection 취약 이 존재한다.

¡ 홈페이지 오류 메시지가 나타날 경우, SQL Injection 가능성이 있으므로 세부 인

검이 필요하다는 것을 의미한다.

조치방법 ¡ ID, Password 란에 특수문자를 입력하지 못하도록 소스코드를 수정한다.

¡ 웹 소스코드 수정이 된 후에 다시 한 번 취약 을 검한다.

5. SQL Injection

35

개요 쿠키를 변조하여 불법 인 인증을 거쳐 웹서버에 근하는 취약

검범 쿠키정보를 통해 개인정보 노출 발생 여부를 확인하기 해 쿠키정보가 암호화

되어 장되었는지를 검한다.

검방법

¡ 로그인을 수행한다.

¡ 웹 라우 주소 창에 javascript:document.cookie; 를 입력하여 쿠키 내용이

암호화되었는지 여부를 확인한다.

조치방법

¡ 가장 효과 인 방법은 SSL과 같은 보안 서버 기능을 용함으로써 로그인

트랜잭션 체를 암호화하는 방법이다.

¡ 쿠키 장 시 타인이 임의로 쿠키를 읽을 수 없도록 도메인과 경로 지정에

유의해야 하며, 라우 에 장되는 쿠키방식보다는 서버 측에 일부 정보를

장하여 상호 조할 수 있는 세션 방식으로 체하고 세션방식의 경우도

사용자의 IP 주소 등을 함께 장하여 유효성 여부를 확인한다.

6. 쿠키 암호화

36

개요 권한이 없는 이용자가 특정 경로를 통해 리자 페이지나 DB에 근할 수 있게

하는 취약

검범 근 통제의 기본이 되는 ID/PW 정보의 노출 리자 홈페이지의 노출 여부를

검한다.

검

방법

구 을

통한

검

방법

¡ 구 사이트에 속한다.

¡ 고 검색으로 이동한다.

¡ 도메인 설정에는 해당 홈페이지 주소를 입력하고 검색어 입력 박스에는

다음을 입력하여 ID/PW 노출 리자 홈페이지 노출 페이지를 찾는다.

­ login | logon

­ password|passcode|비 번호|“your password is"|"당신의 비 번호는”

­ admin | administrator

직

검

방법

¡ 일반 으로 많이 사용하는 리자 페이지 명을 입력하여 리자 페이지가

존재하는지 검한다.

- http://admin.test.go.kr

- http://www.test.go.kr/admin/

- http://www.test.go.kr/manager/

- http://www.test.go.kr/master/

- http://www.test.go.kr/system/

¡ 이용자 인증을 통과하여 페이지에 속한 후, 인증과정없이 간 페이지에

속하여 속이 가능한지 검한다.

조치

방법

구

캐쉬에

노출된

경우

¡ 개인정보 취약 페이지가 구 에 노출된 경우에는 먼 홈페이지에도 개인

정보 취약 노출이 있는지 여부를 확인하여 홈페이지의 개인정보 취약 을

제거 한 후, 구 검색 사이트에 해당 캐쉬에 해 삭제를 요청하는 이메일을

발송한다.

¡ 검색엔진 배제표 을 이용하여 개인정보가 포함된 주소를 지정하는 robot.txt

일을 만들어 서버 루트 디 토리에 장하거나 해당 페이지의 HTML 안에

메타태그를 입력한다.

7. 근통제 취약

37

¡ 개인정보의 노출 정도가 심각하여 긴 하게 노출을 방지하고자 한다면,

구 의 자동 URL 삭제 시스템을 이용하여, URL이 검색되지 않도록 한다.

※ 구 자동 URL 삭제 시스템:

http://services.google.com:8882/urlconsole/controller?cmd=reload&lastcmd=login

직

검을

통해

노출된

경우

¡ 리자 페이지에 임의의 사용자가 근할 수 없도록 리자 페이지에 근

할 수 있는 권한을 가진 단말기만 근 가능하도록 근권한을 설정한다.

¡ 웹 리자 메뉴의 근을 특정 네트워크 역으로 제한하여, IP 주소까지도

인증 요소로 체크하도록 웹 리자 사용자 인터페이스를 개발하고, 리자

인증 후 속할 수 있는 페이지의 경우 해당 페이지 주소를 직 입력하여

속하지 못하도록 리자 페이지 각각에 하여 리자 인증을 한 세션

리를 한다.

38

Ⅳ 학교 홈페이지 구축 운영 시 유의사항

1. 학교 홈페이지 구축․운 지침

○ 우리부에서는 학교 홈페이지를 통해 학생 학부모의 개인정보가

노출되는 것을 방지를 해 다음과 같은 목 으로 학교 홈페이지에

한 구축 운 지침을 수립 시행하고 있습니다.

- 학교 홈페이지의 구축․운 과 련하여 수해야 할 원칙을 규정

- 학교 홈페이지의 질 향상과, 개인정보를 보호하고 유출을 방지하며

교육수요자의 편의성 만족도 제고

○ 상기 : 학교 홈페이지를 구축 운 하는 모든 ․ 등학교

※첨부 : <학교 홈페이지 구축․운 지침> 참조

2. 홈페이지 게시 의 제한 본인 확인제

○「게시 」이란 정보통신망을 이용하여 일반에게 공개할 목 으로

부호․문자․음성․음향․화상․동 상 등의 정보를 이용자가 게재할 수 있는

컴퓨터 로그램 는 기술 장치를 말합니다.

※메일 등 일반에게 공개되지 않는 을 쓸 경우에는 본인확인제의 용을

받지 않습니다.

○ 본인확인제란 이용자가 게시 에 정보를 게시하려고 할 경우, 해당

게시 리․운 자가 게시 이용자의 본인 여부를 확인하는 제도

를 말합니다.

- 따라서 게시 에 정보를 게시하지 않는 단순 이용자의 경우에는

본인확인을 거칠 필요가 없습니다.

- 이는 정보를 게시할 때마다 본인확인을 거칠 필요 없이 한번의 본인

확인을 받고 난 후에는 ID나 별명 등을 사용할 수 있도록 하는 익명

성을 제로 하는 표 의 자유를 여 히 보장하는 제도입니다.

39

○ 본인확인제와 ‘실명제’의 차이

인터넷 이용 시 실명을 사용하고 실명이 표시되는 인터넷 실명제와는

달리 본인확인 후에는 실명 이외의 ID, 별명 등을 사용하여 게시 을

이용할 수 있다는 에서 본인확인제는 익명성을 보장하면서 자유롭

게 인터넷을 이용할 수 있는 제도입니다.

○ 련 법령과 취지

- "정보통신망이용 진 정보보호 등에 한 법률" 동법 시행령

개정(2007.7.27 시행)

- 개정법령 시행에 따라 공공기 ( 공공기 포함)에서는 홈페이지

등 게시 에 홈페이지 이용자가 쓰기, 댓 등을 이용할 경우 본인

확인 차를 거칠 수 있도록 조치하여야 합니다.

※ 본인확인 차 본인확인 정보(성명, 연락처)등은 6개월 보

- 본인확인제 법령의 취지는 웹사이트 게시 상에서 명 훼손, 무고,

악성댓 등에 의한 피해 방, 사 후 분쟁시 본인확인을 통하여

- 선량한 리자의 주의로 본인확인조치 시행 시 이용자의 명의가 제3자에

의하여 부정 사용됨에 따라 발생한 손해에 한 배상책임을 감면 하도록

하 습니다.

○ 우리부 산하기 의 본인확인 조치 의무 상기

- 교육과학기술부 소속기 홈페이지

- 시․도교육청 시군구 교육청(산하기 포함) 홈페이지

- 각 교육기 도 공공기 의 범주에 포함되므로 의무 상기 의

기 에 의거 본인 확인 조치를 수해 것을 권고

※ 분쟁발생시 공공기 의 손해배상 책임 범 등을 감안.

40

Ⅴ 맺음말

본 가이드라인에서는 각 기 의 홈페이지 담당자가 고도의 문 지식이

없더라도 소 홈페이지의 개인정보노출 여부 취약 을 검ㆍ조치할 수

있는 방법을 소개하 습니다. 본 가이드라인을 통해 공공기 홈페이지상의

개인정보노출이 폭 어들 것으로 기 합니다.

홈페이지는 기본 으로 기 의 자료를 외부에 공개하기 한 목 으로

운 되므로, 자칫 리가 소홀해 질 경우 개인정보가 량으로 유출될

가능성이 항상 존재합니다. 이를 해서는 홈페이지 리자의 지속 인

검ㆍ조치도 요하지만, 무엇보다도 홈페이지의 콘텐츠를 생성하는

홈페이지 이용자들의 개인정보보호 인식을 높이는 일이 요합니다. 따라서

각 기 의 홈페이지 리자는 해당 기 의 내부 직원들이 개인정보가

포함된 게시물을 홈페이지에 게제하지 않도록 정기 으로 교육하여야

하며, 홈페이지를 이용하는 민원인 등이 개인정보를 게시 에 게재하지

않도록 주의사항을 고지하는 등 개인정보노출 방지를 해 필요한 조치를

취해야 합니다.

【첨부】

학교 홈페이지 구축․운영 지침

<교육과학기술부>

◦ 학 홈페 지 축․ 과 련하여 준수해야 할 원칙

규정함 로써,

◦ 학 홈페 지 질적 향상과, 개 정보를 보호하고 출

방지하 수 편 성 및 만족도 제고

Ⅰ 학교 홈페이지 구축 및 운영의 본 원칙

□ 구축 분야

1. 홈페이지는 교육수요자의 근과 이용이 편리하도록 구축되어

야 한다.

2. 홈페이지는 교육수요자가 필요로 하는 민원, 정보제공, 참여보장

등의 기능을 충실하게 갖추고 있어야 한다.

3. 홈페이지 련 개인정보, 성 자료 등 요 정보는 홈페이지에

탑재 는 외부 리업체의 산망과 연계해서는 안 된다.

4. 홈페이지는 사이버가정학습 서비스 배 (링크), 학습․자료 등을

탑재하여 원하는 학생들이 학습할 수 있도록 구축되어야 한다.

5. 교육수요자의 알 권리를 보장하기 하여 학교가 가지고 있는

공개 가능한 모든 정보를 제공하여야 한다.

□ 작권 개인정보보호분야

1. 홈페이지에 게재된 내용으로 인한 작권의 침해, 개인정보의

출, 명 훼손 등의 문제가 발생되지 않도록 유의하여야 한다.

2. 이용자의 개인정보 노출에 한 우려를 해소하기 하여 학교 홈페

이지 회원가입 시 실명제를 한 주민등록번호가 필요할 경우

확인 자료로만 이용하고 등록된 기 가입 회원의 주민등록번호

는 공지 후 삭제토록 한다.

3. 홈페이지를 통한 개인정보가 노출 는 유출되지 않도록 자체교

육과 상시모니터링을 실시하는 등 검 리를 강화하여야 한다.

4. 게시 을 통한 개인정보 노출 는 유출을 근원 으로 방지하기

하여 소 트웨어 필터링 기능을 개선하여 수요자가 주민등록번호

를 입력하고자 하는 경우 등록․게재가 되지 않도록 조치한다.

□ 운 분야

1. 학교장은 홈페이지의 효율 인 운 과 리를 한 정한

인력을 갖추고 메뉴별 담당자를 지정하여 운 하여야 한다.

2. 학교홈페이지에서 리목 의 사설업체 홍보(진학상담, 학원,

상품 등) 배 (링크)를 지 한다.

3. 홈페이지는 수시로 업데이트하여 가장 최신의 정보와 자료를 제공하여야 한다.

4. 교육수요자의 참여를 유도할 수 있도록 설문조사 등을 정기 으로

실시하여 홈페이지 개선 교육수요자 서비스 강화에 노력해야 한다.

5. 당해 학교의 지역 특성 교육 여건을 고려한 다양한 내용을

담을 수 있도록 극 노력하여야 한다.

6. 학교장은 정기 으로 홈페이지 취약 을 검하여 개선조치를

취하여야 한다.

Ⅱ 련 근거

▸ 「공공기 홈페이지 구축․운 지침서」(한국 산원, 2003)

▸「행정기 홈페이지 구축 운 표 지침」(교육부, 2005.5)

▸「공공기 의 개인정보보호를 한 기본지침」(행자부, 2006.2)

Ⅲ 홈페이지 구축 세부 지침

1. 기본 인 요구사항

학교 홈페이지가 갖추어야 할 기본 인 요구사항을 충실히

반 하여야 한다.

○ 기 명, 교표

○ 홈페이지의 주소 - 도메인명

○ 학교의 안내

- 교명, 교표 사용

- 교육 목표 안내

- 학교장 역 학교장 소개

- 업무 담당자의 직책, 성명, 화번호(업무용)․FAX 번호․

자우편 등

- 학교의 조직과 구성

- 주요 업무 사업

- 치, 찾아오기(약도, 교통편, 교사 내부 안내 등)

- 학교 체 주소, 화번호, 자우편 등

- 연락처: E-mail 우편 주소, 팩스번호 화번호

○ 개인정보보호방침 설명

○ 련 정보의 제공 검색 기능

○ Q/A, FAQ

○ 도움말 기능

○ 련 교육기 홈페이지와의 링크

○ 작권 보호담당자 내용 링크

○ 교육정보검색시스템(에듀넷, 교수학습지원센터 등)

2. 교육수요자의 참여 보장

○ 교육수요자가 의견을 제시할 수 있는 다양한 방법으로 사이트 구축

- 학교장과의 화창구

- 이용자들의 질문에 학교가 답변하는“온라인게시 ”

- 교육수요자의 의견이나 여론을 조사하기 한 사이버 “설문

조사”, “온라인 투표” 등

3. 개인별 맞춤학습 서비스

○ 교사․학생의 교수․학습 활동을 진할 수 있는 교수학습도

움센터 운

- 교수․학습 자료의 체계 분류 탑재

- 학생들에게 학습 기회 확 를 한 사이버 가정학습 홈페이

지와의 연계 등

4. 다른 교육기 홈페이지의 링크

○ 교육 기 사이트와의 연계

- 교육청, 직속기 홈페이지 등과의 연계

- 사이버가정학습, 교수학습지원센터 등과의 연계

○ 링크는 련정보가 들어있는 특정 웹 페이지로 바로 연결하여

교육수요자의 편의 도모

5. 웹 콘텐츠 표 안 : 【붙임1】참조

○ 인터넷을 통하여 제공되는 각종 정보나 내용물은 텍스트/이미

지/오디오/동 상/ 래시 등의 형태로 제공

○ 콘텐츠 산업의 범 는 출 물, 상물, 게임 소 트웨어를

포함하며, 통 으로 별개의 산업으로 구분되어 있었던 음성,

텍스트 데이터로 제공되는 모든 "정보형태"를 포함

○ 사용자 인터페이스 데이터 련 표 , 명명 규칙(네이

룰), 도메인 리 표 , 기 링크 디 토리 표 , 웹 페이지

링크 표 등 기술표 용

○ 타 검색사이트 등에서 검색 시 네비게이션에 문제가 발생되지

않도록 가 원 임으로 구축

※ 콘텐츠 구성시 유의사항

- 각 기 의 홈페이지 게재 정보는 일반인이 이해하기 쉬운 평

이하고 간결한 용어 문장을 사용하며 필요할 경우 그림․

사진․음성․동화상 등을 극 활용

- 정보게재 갱신시 바이러스 검사 후 게시

Ⅳ 작권 및 개인 보보

1. 작권 개인정보 보호 등을 한 고려

○ 홈페이지 설계(재설계)시 작성된 코드 이미지에도 지 소

유권이 용된다는 사실을 인식하고 구축

○ 홈페이지에 게재되는 모든 정보에 하여 타인의 명 를 손상

시킬 수 있는 요소를 철 하게 확인해야 하며, 명 훼손 시비

를 유발할 여지가 있는 자료는 해당 정보를 사이트에서 삭제

○ 학교 홈페이지에서 개인정보보호는 교육수요자의 라이버

시 보호를 해 매우 요한 문제이므로 공공기 개인정보

보호에 한법률 규정을 수하여 철 하게 리

○ 학교에서는 작권법과 온라인디지털콘텐츠산업발 법 등

련 법령을 수하여 홈페이지에 게시된 자료가 제3자의

작권을 침해하지 않도록 해당 자료에 한 지 소유권자의

허가 등 각별한 주의를 기울일 것

2. 종합 인 안 ․보호 책 마련

○ 학교 홈페이지 회원가입시 본인 확인을 한 주민등록번호

가 필요할 경우 확인 자료로만 이용하고 리목 의 홍보메

일을 요구하지 않아야 하며, 등록된 기 가입 회원의 주민등

록번호는 공지 후 삭제한다.

○ 게시 입력을 통하여 개인정보가 노출 는 유출되지 않도

록 소 트웨어 필터링 기능을 개선하여 교육수요자가 주민등

록번호를 입력하고자 하는 경우 등록‧게재되지 않도록 한다.

○ 개인정보 노출 는 유출에 따른 피해를 없애기 해 개인

식별정보(주민등록번호, 화번호, 휴 폰 번호 등)가 홈페이지

의 공지 사항, 자료실, 게시 등에서 리자‧운 자‧사용자에

의해 노출 는 유출되지 않도록 시스템 리 모니터링 등

극 인 책을 추진하여야 한다.

○ 홈페이지와 학교 내부 정보시스템은 분리하여 운 하여야 한다.

○ 비인가자의 근, 해킹 는 바이러스 등에 의한 사이버테러 등

의 으로부터 시스템을 보호하기 하여 고 홈페이지

서버는 시도교육청 차원에서 리체계를 수립하여야 한다.

○ 데이터의 복구를 한 백업시스템 구축 등 비상사태 처방

안이 수립되어 있어야 한다.

○ 운 서버 등 각종장비가 보 된 산실의 보안 책을 마련

하여 운 하여야 한다.

○ 홈페이지를 통해 이용자의 개인정보 인증정보를 송·수신할

때에는 보안서버 구축 등의 조치를 통해 이를 암호화할 수 있

도록 지원하여야 한다.(정보통신부고시 제2007-3호)

Ⅴ 홈페이지 운영

▸ 홈페이지 게재 정보에 해서는 작권, 정보활용 범 , 정보출처 등을 게재

▸ 홈페이지의 효율 인 운 과 리를 한 정한 조직과 인력 확보

▸ 다른 교육기 홈페이지와의 연계를 하여 한 조치

▸ 학교장은 이 홈페이지 구축․운 지침을 수하고 지침의 범

내에서 당해 기 이나 지역 특성을 고려한 다양한 내용

을 담을 수 있도록 극 노력

1. 홈페이지 운 조직과 인력의 확보

○ 학교장은 홈페이지의 효율 인 리를 한 담 조직과 인력을

반드시 확보

○ 조직 체의 홈페이지 운 부서와 담당자를 지정함은 물론

메뉴별로도 담당자를 지정, 운

○ 주기 으로 홈페이지의 운 개선에 한 의견을 수렴하고

이를 반 함으로써 교육수요자의 극 인 참여 유도

2. 참여의 보장

○ 교육수요자가 제기한 의견이나 건의, 제안, 질문 등에 해서

는 그 처리에 한 답변이 있어야 하며 답변은 개별 으로 하

거나 필요할 경우 공지사항 란에 게재하여 리 알림으로써

참여의 활성화를 유도

○ 불특정 다수인이 의견을 제시할 수 있는 온라인토론방 등에

게시되는 의견이 고성, 특정인의 명 훼손, 기타 불건 한

내용을 담고 있을 경우에는 삭제될 수 있음을 공시

○ 게시 에 게시된 정보를 삭제할 경우, 게시자의 신원 는 연락처

(이메일 주소 포함)를 알 경우에는 즉시 삭제 사실과 이의를

제기할 수 있음을 통보

3. 홈페이지 링크 리

○ 타 기 학교에서 링크를 한 조 요청 시, 해당 학교는

가능한 한 극 으로 조

○ 타 기 의 홈페이지 링크를 통해 정보를 제공하는 학교는 제공정보에

한 작권과 책임을 명확히 하여야 하고 필요시 주의사항을 표시

○ 학교홈페이지에서 리목 의 사설업체 홍보(진학상담, 학원,

상품 등) 배 (링크)를 지

○ 데드링크(Dead Link)가 발생되지 않도록 링크를 정기 으로

검사, 갱신

4. 홈페이지 운 의 평가, 개선

○ 학교는 운 하고 있는 홈페이지를 최소한 연1회 정기 으로

는 수시로 평가하여 취약 을 개선

○ 다른 행정기 이나 민간기 의 홈페이지를 벤치마킹하여

홈페이지의 개선, 발 을 도모

○ 모바일 등 새로운 정보기술을 신속히 도입하여 이용자에게

다양하고 편리한 서비스를 제공하는데 극 노력

○ ‘학교 홈페이지 구축운 지침’을 근간으로 한 당해 학교의

홈페이지 운 계획이나 매뉴얼 수립 용

○ 홈페이지를 개편할 경우에는 미리 개편 계획을 공지하여,

이용자의 의견을 개편에 반 하도록 하며 개편 시 이용자들에

게 불편함을 주지 않아야 함

-끝-