1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
|
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
<!-- English Revision: 106090 -->
<!--
Copyright 2004 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="auth.xml.meta">
<parentdocument href="./">How-To / Tutorials</parentdocument>
<title>인증(Authentication), 권한부여(Authorization),
접근제어(Access Control)</title>
<summary>
<p>인증(authentication)은 자신이 누구라고 주장하는 사람을
확인하는 절차이다. 권한부여(authorization)는 가고 싶은 곳으로
가도록 혹은 원하는 정보를 얻도록 허용하는 과정이다.</p>
</summary>
<section id="related"><title>관련 모듈과 지시어</title>
<related>
<modulelist>
<module>mod_auth</module>
<module>mod_access</module>
</modulelist>
<directivelist>
<directive module="mod_access">Allow</directive>
<directive module="mod_auth">AuthGroupFile</directive>
<directive module="core">AuthName</directive>
<directive module="core">AuthType</directive>
<directive module="mod_auth">AuthUserFile</directive>
<directive module="mod_access">Deny</directive>
<directive module="core">Options</directive>
<directive module="core">Require</directive>
</directivelist>
</related>
</section>
<section id="introduction"><title>소개</title>
<p>당신의 웹사이트에 있는 정보가 소수의 사람들만의 비밀이거나
이들만을 위한 정보라면, 이 글에서 설명하는 기법을 사용하여
당신이 보길 원하는 사람만 페이지를 보도록 할 수 있다.</p>
<p>이 글은 웹사이트의 일부를 보호하기위해 많은 사람들이
사용하는 "표준적인" 방법을 다룬다.</p>
</section>
<section id="theprerequisites"><title>기본 지식</title>
<p>이 글에서 다루는 지시어는 서버의 주설정파일(일반적으로
<directive module="core" type="section">Directory</directive>
섹션)이나 디렉토리별 설정파일(<code>.htaccess</code> 파일)에서
사용한다.</p>
<p><code>.htaccess</code> 파일을 사용하려면 이 파일에 있는
인증 지시어를 허용하도록 서버를 설정해야 한다. 이를 위해
디렉토리별 설정파일에 어떤 지시어를 사용할 수 있는지를 결정하는
<directive module="core">AllowOverride</directive> 지시어를
사용한다.</p>
<p>여기서는 인증을 다루기 때문에, 다음과 같은
<code>AllowOverride</code> 지시어가 필요하다.</p>
<example>
AllowOverride AuthConfig
</example>
<p>혹은 지시어를 직접 서버 주설정파일에 적는다면, 그 파일에
쓰기 권한이 물론 있어야 한다.</p>
<p>그리고 보호할 파일이 어디있는지 알기위해 서버의 디렉토리
구조에 대해 조금 알아야한다. 이 일은 어렵지않고, 적당한
때에 자세히 설명할 것이다.</p>
</section>
<section id="gettingitworking"><title>기본적인 설정하기</title>
<p>이제 서버의 디렉토리를 암호로 보호하는 기본적인 방법을
설명한다.</p>
<p>먼저 암호파일을 만들어야 한다. 이 파일은 웹에서 접근할
수 없는 곳에 있어야 한다. 다른사람이 암호파일을 다운로드하지
못하게하기 위해서다. 예를 들어, 문서들이
<code>/usr/local/apache/htdocs</code>에 있다면 암호파일(들)은
<code>/usr/local/apache/passwd</code>에 둔다.</p>
<p>아파치에 포함된 <a
href="../programs/htpasswd.html">htpasswd</a> 도구를 사용하여
암호파일을 만든다. 이 프로그램은 아파치를 설치한 곳의
<code>bin</code> 디렉토리에 있다. 파일을 만들려면 다음과
같이 입력한다.</p>
<example>
htpasswd -c /usr/local/apache/passwd/passwords rbowen
</example>
<p><code>htpasswd</code>는 암호를 물어보고, 확인을 위해
암호를 다시 입력하라고 요청한다.</p>
<example>
# htpasswd -c /usr/local/apache/passwd/passwords rbowen<br />
New password: mypassword<br />
Re-type new password: mypassword<br />
Adding password for user rbowen
</example>
<p>물론 <code>htpasswd</code>이 실행파일 경로에 없다면
실행파일의 전체 경로를 입력해야 한다. 내가 사용하는 서버에서는
<code>/usr/local/apache/bin/htpasswd</code>에 실행파일이
있다.</p>
<p>다음으로 서버가 암호를 요청하도록 설정하고, 서버에게
어떤 사용자의 접근을 허용할지 알려줘야 한다.
<code>httpd.conf</code>를 편집하거나 <code>.htaccess</code>
파일을 사용하여 설정한다. 예를 들어,
<code>/usr/local/apache/htdocs/secret</code> 디렉토리를
보호하려면, 아래 지시어를
<code>/usr/local/apache/htdocs/secret/.htaccess</code> 파일이나
<code>httpd.conf</code>의 <Directory
/usr/local/apache/apache/htdocs/secret> 섹션에 적어야
한다.</p>
<example>
AuthType Basic<br />
AuthName "Restricted Files"<br />
AuthUserFile /usr/local/apache/passwd/passwords<br />
Require user rbowen
</example>
<p>지시어를 하나씩 살펴보자. <directive
module="core">AuthType</directive> 지시어는 사용자를 인증할
방법을 선택한다. 가장 일반적인 방법은 <code>Basic</code>으로,
<module>mod_auth</module>가 구현한다. 그러나 Basic
인증은 브라우저가 서버로 암호를 암호화하지 않고 보낸다.
그러므로 기밀 자료를 보호하기위해 이 방법을 사용하면 안된다.
아파치는 <code>AuthType Digest</code>라는 인증 방법도 지원한다.
이 방법은 <module>mod_auth_digest</module>가 구현하며, 매우
안전하다. 가장 최근 클라이언트들만이 Digest 인증을 지원한다고
한다.</p>
<p><directive module="core">AuthName</directive> 지시어는
인증에 사용할 <dfn>영역(realm)</dfn>을 지정한다. 영역은
두가지 역할을 한다. 첫번째는 클라이언트가 보통 이 정보를
암호 대화창에 보여준다. 두번째는 영역 정보를 사용하여
클라이언트가 특정 인증구역에 어떤 암호를 보낼지 결정한다.</p>
<p>예를 들어, 일단 클라이언트가 <code>"Restricted Files"</code>
영역에 인증이 성공하였다면, 클라이언트는 자동으로 같은 서버에서
<code>"Restricted Files"</code> 영역으로 표시된 구역에 대해
동일한 암호를 시도한다. 그래서 여러 제한 구역이 같은 영역을
공유하면 사용자가 여러번 암호를 입력하지 않아도 된다. 물론
보안상 이유로 클라이언트는 서버의 호스트명이 다르면 항상
새로 암호를 물어본다.</p>
<p><directive module="mod_auth">AuthUserFile</directive>
지시어는 우리가 방금 <code>htpasswd</code>로 만든 암호파일의
경로를 설정한다. 사용자가 많다면 요청마다 매번 사용자를
인증하기위해 일반 문서파일을 검색하는데 시간이 상당히 많이
걸릴 수 있다. 아파치는 빠른 데이타베이스 파일에 사용자 정보를
저장할 수 있다. <module>mod_auth_dbm</module> 모듈은 <directive
module="mod_auth_dbm">AuthDBMUserFile</directive> 지시어를
제공한다. <a href="../programs/dbmmanage.html">dbmmanage</a>
프로그램을 사용하여 암호파일을 만들고 다룬다. <a
href="http://modules.apache.org/">아파치 모듈
데이타베이스</a>에는 여러 다른 인증 방식을 제공하는 제삼자가
만든 모듈들이 있다.</p>
<p>마지막으로 <directive module="core">Require</directive>
지시어는 서버의 특정 영역에 접근할 수 있는 사용자를 지정하여
권한부여를 한다. 다음 절은 <code>require</code> 지시어를
사용하는 다양한 방법을 설명한다.</p>
</section>
<section id="lettingmorethanonepersonin"><title>여러명을 들여보내기</title>
<p>위의 지시어는 디렉토리로 (사용자명이 <code>rbowen</code>인)
한 사람만을 들여보낸다. 대부분의 경우 여러 사람을 들여보내고
싶을 것이다. 이제 <directive
module="mod_auth">AuthGroupFile</directive>을
사용할 때다.</p>
<p>여러 사람을 들여보내고 싶다면 그룹명과 그 그룹에 어떤
사용자들이 있는지 알려주는 그룹파일이 필요하다. 이 파일의
형식은 매우 간단하여, 아무 편집기로나 만들 수 있다. 파일내용은
다음과 같다.</p>
<example>
GroupName: rbowen dpitts sungo rshersey
</example>
<p>그냥 공백으로 구분한 긴 그룹 구성원 목록일 뿐이다.</p>
<p>기존의 암호파일에 사용자를 추가하려면 다음과 같이 입력한다</p>
<example>
htpasswd /usr/local/apache/passwd/passwords dpitts
</example>
<p>전과 같지만, 새로 파일을 만들지 않고 기존 파일에 사용자를
추가한다. (<code>-c</code> 옵션은 새로 암호파일을 만든다).</p>
<p>이제 <code>.htaccess</code> 파일을 다음과 같이 수정한다.</p>
<example>
AuthType Basic<br />
AuthName "By Invitation Only"<br />
AuthUserFile /usr/local/apache/passwd/passwords<br />
AuthGroupFile /usr/local/apache/passwd/groups<br />
Require group GroupName
</example>
<p>그러면 <code>GroupName</code> 그룹에 속하며
<code>password</code> 파일에 항목이 있는 사용자가 올바른
암호를 입력하면 접근을 허용한다.</p>
<p>여러 일반 사용자를 들여보내는 다른 방법이 있다. 그룹파일을
만들 필요없이 다음 지시어를 사용하기만 하면 된다.</p>
<example>
Require valid-user
</example>
<p><code>Require user rbowen</code> 대신 이 지시어를 사용하면
암호파일에 있는 누구라도 올바른 암호를 입력하기만 하면 접근을
허용한다. 그룹별로 다른 암호파일을 사용하여 그룹과 비슷한
효과를 얻을 수도 있다. 이 경우 아파치가 파일 두개(암호파일과
그룹파일)가 아닌 파일 한개(암호파일)만 검사하면 된다는 것이
장점이다. 그러나 여러 암호파일을 관리해야 하고, <directive
module="mod_auth">AuthUserFile</directive> 지시어에
정확한 암호파일을 지정해야 하는 것은 단점이다.</p>
</section>
<section id="possibleproblems"><title>발생할 수 있는 문제점</title>
<p>Basic 인증 방식은 서버에서 문서를 요청할 때마다 사용자명과
암호를 확인한다. 심지어 같은 페이지를 새로 고침할 때도 페이지와
(그림이 암호로 보호하는 디렉토리에 있는 경우) 페이지에 있는
모든 그림에 대해 다시 확인한다. 짐작하듯이 속도가 조금 느려진다.
암호파일을 열어서 사용자명을 찾을 때까지 사용자 목록을 살펴봐야
하기때문에 암호파일 크기가 커질 수록 더 느려진다. 그리고
이 작업을 페이지를 요청할 때마다 진행한다.</p>
<p>그래서 현실적으로 한 암호파일에 저장할 수 있는 사용자수에는
한계가 있다. 이 한계는 사용하는 서버의 성능에 따라 다르지만,
항목이 수백개가 넘는다면 느려진다고 생각하고 다른 인증 방법을
고려해야 한다.</p>
</section>
<section id="whatotherneatstuffcanido"><title>다른 방법도 가능한가?</title>
<p>사용자명과 암호를 사용한 인증이 다가 아니다. 종종 접속한
장소와 같은 다른 정보를 가지고 사용자를 들여보내고 싶을
때가 있다.</p>
<p><directive module="mod_access">Allow</directive>와
<directive module="mod_access">Deny</directive> 지시어는
문서를 요청한 컴퓨터의 호스트명 혹은 호스트 주소를 가지고
접근을 허용하거나 거부한다. <directive
module="mod_access">Order</directive> 지시어는 이 두
지시어와 같이 사용하여, 아파치에게 어떤 순서로 규칙을 적용할지
알린다.</p>
<p>이들 지시어 사용법은 다음과 같다.</p>
<example>
Allow from <var>address</var>
</example>
<p>여기서 <var>address</var>는 IP 주소(혹은 IP 주소 일부)나
완전한 도메인명(혹은 도메인명 일부)이다. 원한다면 여러 주소나
도메인명을 사용할 수 있다.</p>
<p>예를 들어, 누군가가 게시판에 광고를 올리고 있다면 다음과
같이 접근을 막을 수 있다.</p>
<example>
Deny from 205.252.46.165
</example>
<p>그 주소에서 들어오는 방문자는 이 지시어가 보호하는 페이지를
볼 수 없다. IP 주소 대신 다음과 같이 컴퓨터명을 사용할 수도
있다.</p>
<example>
Deny from <var>host.example.com</var>
</example>
<p>또, 전체 도메인의 접근을 막으려면 주소나 도메인명의 일부를
사용한다.</p>
<example>
Deny from <var>192.101.205</var><br />
Deny from <var>cyberthugs.com</var> <var>moreidiots.com</var><br />
Deny from ke
</example>
<p><directive module="mod_auth">Order</directive>를
<directive module="mod_auth">Deny</directive>와 <directive
module="mod_auth">Allow</directive> 지시어와 같이
사용하여 실제로 원하는 대상을 막을 수 있다.</p>
<example>
Order deny,allow<br />
Deny from all<br />
Allow from <var>dev.example.com</var>
</example>
<p><directive module="mod_auth">Allow</directive>
지시어만 사용하면, 해당 호스트의 사용자를 허용하고 거기에
추가로 모든 사람을 허용하므로 원하는 결과를 얻지 못한다.
당신은 특정 사람<em>만</em> 허용하길 원한다.</p>
</section>
<section id="moreinformation"><title>더 많은 정보</title>
<p><module>mod_auth</module>와
<module>mod_access</module> 문서에 접근제어가 동작하는
방법에 대한 더 많은 정보가 있다.</p>
</section>
</manualpage>
|
