good old 의 의미는?

[정론직필]

아래 내용을 소개한다고 해서....여러분들이 아래 내용을 모두 읽어야 한다는

의미가 아닙니다. 아래와 같은 내용은 솔직히 나도 읽기 싫으네요.

왜냐면 도무지 나에게 별로 소용되는 일이 없는 내용이기 때문이지요.

그러나 만일 컴퓨터 프로그래밍을 하는 사람들이나 데이터베이스 관리자라면

반드시 읽어 보아야 할 내용이겠지요.

나의 관심은 오로지.....우연히 발견한 아래 영문에서

두번째 문단에 있는  good old이라는 두 단어의 의미입니다.

대개 good은 "좋은"이라는 우리말로 번역되고

old는 "나이든" 또는 "오래된"이라는 의미로 번역되는 단어들이죠.

그렇다면.....아래 문장에서도 그와같은 의미로 사용되고 있을까요?

MS SQL

August 5, 2002

Securing SQL Server for Web Applications

By Andrew Novick

If your SQL Server is exposed to the Internet, hackers are probing it. Probably right now. This article shows how to secure a SQL Server database that's being used with a Web application. By definition these servers are exposed.

Not sure that there is a problem? We'll start with the two elements that create the problem: vulnerabilities in Windows, IIS, and SQL Server and the attacks that attempt to exploit them. As Microsoft has increased its focus on security, the number of hot fixes for SQL Server has been on the rise. However, the most exploited vulnerability is still the good old blank password for the SA account.

There Are Vulnerabilities in SQL Server

Like all software SQL Server has security vulnerabilities. Documentation for the vulnerabilities that Microsoft is willing to talk about is located at: www.microsoft.com/technet/security/current.asp?productid=30&servicepackid=0. 

You'll find half a dozen or more SQL Server specific security bulletins and information about patching them. It seems a new vulnerability is found almost every week. Start by making sure your SQL Server has all the latest and greatest hot fixes. Later on we'll talk about the tools that go out to the net to check for updates.

The most widespread attack isn't covered by a security bulletin. It's a straightforward login attempt made on the SA account with a blank password. 

Since some administrators never bother to change the default password, there are ample victims to be infected. Microsoft doesn't even consider this vulnerability and won't be issuing a patch. After all, the blank password is "by design". See Microsoft Knowledge Base article Q313418 at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q313418

A common cause of the blank password is products. For example some versions Visio install MSDE and never change the SA password. The user may not even know that they have MSDE running. To check your network you can download a program that scans for SQL Servers with SA accounts that have blank passwords on your network. It's from eEye, a security company that spends a lot of time looking for wholes in Microsoft products. Download it at:http://www.eeye.com/html/Research/Tools/sqlworm.html.

Figure 1 shows the tool after it has scanned only one address, 127.0.0.1, the local system. You can use it to scan entire ranges of addresses to find vulnerable SQL Servers you may not know about.

                        Figure 1

Attack of the Clones!

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.

Sun-Tzu

I was shocked when I learned of the extent of the probes flying around the Net. It's worthwhile to understand what's going on out there. Sites such as Internet Storm Center (http://isc.incidents.org) track the frequency of worms, Denial-Of-Service attacks (DOS) and other hacks. Right now they're reporting on high incidence of port 1433 scans looking for SQL Servers with blank passwords for the SA account. We're talking about thousands of computers making 750,000 reported probes a day. Most probes go unreported, so there are really millions of actual probes.

Another places to look for information on Web attacks is www.securityfocus.com (see the article http://online.securityfocus.com/archive/75/272790). For information about operating system, IIS and SQL Server bugs that may or may not affect security, I rely on www.ntbugtraq.com. For virus information I often look to http://securityresponse.symantec.com/. Your virus detection vendor probably has their own site.

Many of the above sites have e-mail notification services. Relying on them is easier than checking the sites daily. Be sure you're getting Microsoft's security bulletin notifications, which you'll find at: http://www.microsoft.com/technet/security/notify.asp.

Goals

Now that we've established that there is a problem, let's step back a minute. What are we really trying to do when we say, "Secure our SQL Server?" My list is:

• Protect the server from attack.
• Detect attacks that cannot be prevented so that the holes can be closed later.
• Fulfill any due diligence responsibility that I have as an administrator and that my clients may have to their stockholders, clients and business partners. In other words, CYA.

Protecting the SQL Server from attack will include:

• Setting Windows and up the network
• Configuring accounts used by Windows Services such as IIS and SQL Server
• Configuring SQL Server

Detecting attacks is primarily a matter of logging and checking the logs. We'll go over this in detail soon.

Do You Need a Written Security Policy?

Some sources suggest that you should document very specific goals for security. Specifically:

• What resources are you protecting? For example: ABC and XYZ SQL Servers, DEF Web server.
• Why are they being protected? For example: "It contains private information about individuals."

I like written policies, but create them with care. Although I'm not a lawyer and don't give legal advice, I'm pretty sure that once you adopt a written policy, you'd better follow it. If you don't, someone, someday may decide that you hadn't exercised your "due diligence" in protecting the resources that were under your care, and your written policy is evidence against you.

Securing Windows

Before you can have a secure SQL Server, you must have a secure Windows server and network. I've covered these in previous articles that you might want to take a look at. They are: Protecting Your IIS Server and Web Application and Complying with IT's Security Requirements for Web Applications.

Setting Up the Network

There are two topologies that you might consider when setting up your network. Figure 2 shows the first where IIS and SQL Server are on one server. It's the simpler configuration and can be employed inside a DMZ.

                                                   Figure 2

Splitting IIS and SQL Server onto two servers has its advantages. For starters, SQL Server can be inside your internal network behind a second firewall. Being on the inner network can be important when the SQL Server is used by more than just the Web application. Figure 3 shows the split network setup. Two Firewalls are employed creating what is commonly referred to as a DeMilitarized Zone or DMZ. Web traffic, HTTP on Port 80 or 1443, is allowed only as far as the Web server. The Web server communicates with the SQL Server over TCP on Port 1433.

                                       Figure 3

To protect the communications between the IIS server and the SQL Server, you can use a protocol other than TCP/IP or a port other than 1433 and turn on protocol encryption. SQL Server 2000 supports encryption using all protocols. 

Using something other than the default settings will prevent anyone that is sniffing on network traffic from understanding what is transmitted. Of course, as with other security measures, there is a price to pay in performance. Encryption and decryption slow network traffic.

Running components in COM+ complicates the picture even further. They can be run on one of the existing servers or on a third server. You'll place the COM+ server inside the inner firewall of your DMZ and set up communications between it and the machine with IIS. I've always placed my components on the machine with IIS, which limits the complexity.

Windows Services Accounts

Even though there is no login screen, every program that runs as a service must log into Windows as a particular user with a matching password. This applies to IIS, COM+ components, SQL Server and SQL Server Agent. Choosing which account each process runs as is important to securing your system, managing performance, and avoiding driving yourself crazy when programs stop working. There are a lot of possible combinations, so we'll touch on the most important choices here.

For starters, each account involved must be either a domain account or a local account. Checking with a Domain Controller authenticates domain accounts. Local accounts are checked in the SAM database on the local machine. In some ways using a domain account is more secure. Be aware that each time an account is authenticated a network round trip is made to the domain administrator and back.

Privileges requested from another computer require the use of either a domain account or local accounts with identical user id and password. For example, if a process such as IIS or COM+ wants to communicate with SQL Server using the Named Pipes protocol, a Domain account must be used. That's because Named Pipes is implemented by connecting via the IPC$ network share, a protected resource.

For IIS or a COM+ component to connect to SQL Server, it must either supply a SQL Server login ID and password, or use Integrated Security. SQL Server logins are created in SQL Server and are administered either with script or Enterprise manager. Integrated Security, sometimes referred to as Windows Authentication, means: logging in using a Windows Domain account. So using Integrated Security implies that IIS or the COM+ component must be running as a Windows 

Domain account.

In Intranet scenarios, users have their own Windows accounts and these accounts can be relied on by selecting "NT Challenge Response" authentication in IIS. When this is used, IIS impersonates the user's Windows account when accessing SQL Server. The users' Windows account or group must be given login rights in SQL Server. Being able to manage logins on a group basis greatly simplifies the process of maintaining security because as new users are given Windows logins, they automatically gain the SQL Server login rights corresponding to the groups they belong to.

Overall, in an Intranet, the secure choice is to use Integrated Security and Integrated Security only. In SQL Server 2000 this is referred to as "Windows Only" security mode. The security mode is set up only with Enterprise Manager or SQL-DMO. There is no T-SQL Script equivalent to change security mode. The Authentication section near the top of Figure 4 shows the choice of "Windows only" security.

              Figure 4

(이하 생략)

http://www.databasejournal.com/features/mssql/article.php/1439641

[횡설수설]

오래됐지만... 친숙한...사용하기 편한.... 이런 뜻이라 생각했는데, 사전에도 그렇게 나와 있네요.

good old

informal ? used before a noun to describe a familiar person or thing with affection or approval ? Good old John: you can always count on him to help. ? I don't need fancy shoes. I prefer good old sneakers. ? They were talking about the good old days. [=happy times in the past]

[횡설수설]

간만에 들렀는데... 카페지기만... 홀로 지키고 계시네요. 마음이 닫혀 있다가 최근에 맘에 여유가 생겨 들러봤습니다. 앞으로 자주 오도록 하겠습니다. ^^

[제임스]

잘 보았습니다.