• 카테고리
    • 전체 글

    • 카테고리1
    • 카테고리2
    • 카테고리3
    • 카테고리4
  • 태그
  • 방명록

'2006/11'에 해당되는 글 8건

  • 2006.11.30 The COM Elevation Moniker
  • 2006.11.30 가상 회사 Litware Inc. 만들기. 2
  • 2006.11.24 대하드라마 요시츠네(義經)
  • 2006.11.24 About Office SharePoint 2007
  • 2006.11.23 Programing의 새로운 파라다임.
  • 2006.11.17 Windows Vista RTM에 이어 Office 2007 RTM이 나왔었구나..
  • 2006.11.07 현재 내 ICQ 안에는...
  • 2006.11.06 내 ICQ 번호 2

The COM Elevation Moniker

기술자료/OS 2006. 11. 30. 22:50

이 문서내의 내용의 오역으로 인한 피해에 대해서는 절대 책임지지 않습니다. 반드시 원문을 보시고, 제가 작성한 문서는 단지 참고만 하시기 바랍니다.

문서 원본 위치
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/1595ebb8-65af-4609-b3e7-a21209e64391.asp
The COM Elevation Moniker  
- Windows Vista에서 COM 개체의 접근 권한 상승 시키기.

COM을 이용한 권한 상승 Moniker란, 사용자 계정 권한 제한(Limited User Accout : LUA )하에서 동작 해야 하는 응용 프로그램이 권한 상승을 할 수 있도록, COM 클래스의 활성화 작업을 수행하는 것입니다. LUA에 대한 더 자세한 사항은 Security in Longhorn : Focus on Least Privilege을 보시기 바랍니다.

Elevation Moniker를 사용할 때
Elevation moniker란, 권한이 제한된 상태로 실행 중인 COM 클래스가 시스템 날짜 및 시간을 설정하는 것과 같이,높은 권한을 필요로 하는 경우 해당 권한을 활성화 주는 것을 말합니다.
권한 상승 작업은 COM 클래스 자체 뿐만 아니라, COM 클래스를 사용하는 클라이언트까지, 두가지다 필요합니다. 먼저 COM 클래스는 권한 상승을 하기 위한 설정 작업으로 자신의 레지스트리 항목 중 Requirements 섹션에 별도의 기록을 수행해야 합니다. 그리고, COM 클라이언트는 별두 작업을 수행하기 보다, 권한 상승 Moniker을 이용하여 권한 상승요청을 하면 됩니다.
권한 상승 Moniker 자체는 응용 프로그램 호환성을 고려하여 구성하지 않았습니다. 즉 보안을 중심으로 고려하였기 때문에, 별도의 우회적인 회피방법을 제시하진 않습니다. 그래서 과거의 COM 클래스와 클라이언트 간의 권한 상승 문제로 응용 프로그램 호환성 오류가 발생할 수 있습니다. 예를 들어, WinWord와 같이 권한 상승을 높아야 하는 기존 COM 클래스를 COM 클라이언트에서 실행하려면, COM 클래스 뿐만 아니라, COM 클래스를 이용하는 클라이언트도 권한 상승 Moniker로 활성화 시켜야 합니다.
단, 기존 COM 클래스의 CLSID로 CoCreateInstance를 호출해 COM 클라이언트의 권한을 상승 시켰어도, COM 클라이언트의 권한은 COM 서버 프로세스의 권한을 따라가게 됩니다.  물론, 모든 COM 자체의 기능 수행에 반드시 권한 상승이 필요한 것은 아니지만, 다음과 같은 제한들로 정상적으로 동작하지 않을 것입니다.

  • COM 클라이언트의 권한이 높더라도 원격 COM 서버의 권한까지 높아지는 것은 아닙니다. 클라이언트가 권한 상승 Moniker로 권한 상승을 했다고 하더라도, COM 서버 자체가 자동적으로 권한 상승되진 않습니다.
  • 만일 권한 상승된 COM 클래스가 COM 호출 시 impersonation(가장화)를 사용할 때, impersonation(가장화) 중에 상승된 권한을 잃게 될지 모릅니다.
  • 만일 권한 상승된 COM 서버가 Running Object Table(ROT)상에 클래스를 등록할 때, 권한 상승되지 않은 클라이언트에서는 그 클래스를 활용하지 못합니다.
  • 중간(Medium) 보다 높은 통합 레벨(Integraity Level : IL )로 동작하는 프로세스는 COM 활성화 중에 사용자 별 클래스를 적재 할 수 없습니다. 만일 COM 응용 프로그램이 Administrators 급 계정이던 아니던 간에 사용하게 하려면, HKEY_LOCAL_MACHINE 레지스트리 상에 응용 프로그램의 COM 클래스가 설치되어 있어야 합니다. 만일 Administrators 급 계정에서만 응용 프로그램을 사용하게 된다면 응용 프로그램 COM 클래스는 반드시 HKEY_USERS 쪽에 설치하셔야 합니다.
  • 권한 상승되지 않은 응용 프로그램에서 상승된 응용 프로그램쪽으로 드래그 앤 드랍을 지원하지 않습니다.

필요사항
COM 클래스를 활성화 하기 위해 권한 상승 Moniker를 사용하기 앞서 클래스는 반드시 실행 사용자 또는 '활성자로써 활성화(Activate as Activator)'의 응용 프로그램 ID로 실행 할 수 있도록 설정되어 있어야 합니다. 만일 클래스가 여타 다른 ID하에서 실행되도록 설정하려면, Activation에서는 CO_E_RUNAS_VALUE_MUST_BE_AAA 에러를 돌려주게 됩니다.
클래스에서는 반드시 다중 언어 사용자 인터페이스(MUI) 호환이 되는 "친숙한" 표시 이름으로 되어 있어야 합니다. 여기서는 다음과 같은 레지스트리
항목이 필요하게 됩니다.:

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\

  {CLSID}\LocalizedString = <displayname>

만일 항목이 빠진 경우, Activation에서는 CO_E_MISSING_DISPLAYNAME 에러를 돌려주게 됩니다. 만일 MUI 파일이 빠진
경우 RegLoadMUIStringW API에서 에러 코드를 돌려주게 됩니다.
추가적으로, LUA 사용자 인터페이스에서 보여주게 될 응용 프로그램 아이콘을 표시하려면 다음 레지스트리 키를 추가해 줍니다.:

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\

  {CLSID}\IconReference = <applicationicon>

COM 클래스에서는 LUA-Enabled 와 같은 표시가 반드시 필요합니다. 이 사항을 적용하려면 다음과 같은 레지스트리 항목을 추가하시면 됩니다.

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\

  {CLSID}\Elevation\Enabled = 1

만일 항목이 빠져 있는 경우 Activation에서는 CO_E_ELEVATION_DISABLED이라는 에러를 돌려주게 됩니다.
HKEY_LOCAL_MACHINE 항목 상에 이들 항목이 있는 경우, HKEY_CURRENT_USER 및 HKEY_USERS 항목에서는 없어야
합니다. 이는  COM 클래스의 권한 상승을 레지스트리 등록 권한이 없는 사용자가 멋대로 등록하는 경우를 방지하기 위해서 입니다.

권한 상승 Moniker 및 권한상승 UI
만일 클라이언트가 이미 권한 상승 Moniker로 권한 상승이 된 경우, 권한 상승 UI를 보여주지 않게 합니다.

권한 상승 Moniker를 사용하는 방법
권한 상승 Moniker는 표준 COM Moniker이며, 세션, 파티션 또는 큐 형태의 Moniker들과 유사합니다. 특정 권한 레벨을 특정 서버에 활성 요청을 관리합니다.Moniker 문자열에서 활성화 할 CLISID를 나타냅니다.
권한 상승 Moniker에서는 다음과 같은 실행 레벨 토큰들을 지원합니다.

  1. Administrator(관리자).
  2. Highest(높음).

이 사항에 대한 문접은 다음과 같습니다.

[code]
Elevation:Administrator!new:{guid}
Elevation:Highest!new:{guid}
[/code]

앞의 문법 중에서 해당 GUID의 COM 클래스의 새로운 인스탄스를 받으려면 "new" Moniker를 사용하면 됩니다. 여기서 "new" Monker에서는 클래스 객체를 탑재한 후 IClassFactory::CreateInstance를 호출하기 위해 IClassFactory interface 를 내부적으로 사용한다는 것에 주의해주시기 바랍니다.
또한 권한 상승 Moniker가 IClassFactory를 구현하기 위해 클래스 객체를 얻을 때 이용 될 수 있습니다.그리고 호출자에서는 객체 인스탄스를 얻기 위해 IClassFactory::CreateInstance 를 호출하게 됩니다. 이 사항에 대한 문법은 다음과 같습니다.

[CODE] Elevation:Administrator!clsid:{guid} [/CODE]

예제 코드
다음 예제 코드에서는 어떻게 권한 상승 Moniker를 사용하는지에 대한 내용입니다. 이 부분의 의미하는 사항은 현재 쓰레드 상에서 이미 초기화 된 COM을 나타내는 것입니다.

[CODE] HRESULT CoCreateInstanceAsAdmin(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv) {   BIND_OPTS3 bo;   WCHAR  wszCLSID[50];   WCHAR  wszMonikerName[300];

  StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0]));   HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);   if (FAILED(hr))        return hr;   memset(&bo, 0, sizeof(bo));   bo.cbStruct = sizeof(bo);   bo.hwnd = hwnd;   bo.dwClassContext  = CLSCTX_LOCAL_SERVER;   return CoGetObject(wszMonikerName, &bo, riid, ppv); } [/CODE]

BIND_OPTS3은 Windows Vista에서 새롭게 등장한 사항입니다. 이 부분은 BIND_OPTS2에서 상속 받은 사항으로 다음과 같은 형태로 정의되어 있습니다.

[CODE] typedef struct tagBIND_OPTS3 : tagBIND_OPTS2 {   HWND hwnd; } BIND_OPTS3, * LPBIND_OPTS3; [/CODE]

한가지 추가적인 사항은 HWND 필드, hwnd가 있습니다.이 핸들은 대부분의 경우 권한 상승 UI의 부모가 될 윈도우를 나타내게 됩니다.
만일 hwnd가 NULL인 경우 COM은 현재 스레드에 관련된 Window Handle을 찾기 위해 GetActiveWindow를 호출하게 됩니다. 클라이언트가 스크립트로 구성되어, 발생되는 경우로 BIND_OPT3 구조체의 정보가 불완전하게 담기게 됩니다. 이 경우, COM에서는 스크립트 스레드와 관련된 Window를 사용하도록 시도하게 됩니다.

Over-The-Shoulder 권한 상승(OTS)
Over-the-shoulder 권한 상승 (Over-the-shoulder elevation : OTS)은 사용자 자체 권한 이라기 보다 관리자 권한을 가진 사용자의 권한으로 COM 서버가 동작하는 클라이언트에서 볼 수 있는 시나리오 상황 입니다.(Over-the-shoulder 의 의미는 사전적으로 훔쳐보다로써, 클라이언트가 서버를 동작시키는 것과 같이 클라이언트 권한 밖에서 관리자 처럼 동작시키는 것을 의미합니다.)
이 시나리오에서는 서버로 COM을 호출하는 문제를 발생시킬 수 있습니다. 그 이유로는 서버가 명확하거나(대부분 프로그램 로직상으로), 무조건적으로(정확히 말하자면, 레지스트리를 이용하여) CoInitializeSecurity를 호출하지 못하기 때문입니다. 그런 서버들 때문에, COM에서는 서버로 COM을 호출 할 수 있도록 SELF, SYSTEM 및 Builtin\Administrators를 나타내는 보안 명세서를 산정하게 됩니다.이 명세서는 OTS 시나리오에서 동작하지 않습니다. 대신에 서버는 INTERACTIVE SID 및 System Group을 포함하는 ACL을 명시에 명확하고 무조건적적으로 방법을 벗어나 CoInitializeSecurity를 반드시 호출하게 해줍니다.
다음 예제 코드에서는 INTERACTIVE group SID로 보안 명세서(security descriptor : SD)를 어떻게 생성하는지 보여주게 됩니다.

[CODE] BOOL GetAccessPermissionsForLUAServer(SECURITY_DESCRIPTOR **ppSD) { // Local call permissions to IU, SY   LPWSTR lpszSDDL = L"O:BAG:BAD:(A;;0x3;;;IU)(A;;0x3;;;SY)";   SECURITY_DESCRIPTOR *pSD;   *ppSD = NULL;   if (ConvertStringSecurityDescriptorToSecurityDescriptorW(lpszSDDL, SDDL_REVISION_1, (PSECURITY_DESCRIPTOR *)&pSD, NULL))   {        *ppSD = pSD;        return TRUE;   }    return FALSE; } [/CODE]

다음 예제 코드는 이전 예제 코드에서 SD로 명확하게 CoInitializeSecurity를 호출하는 방법을 보여줍니다.

[CODE] // hKey is the HKCR\AppID\{GUID} key BOOL SetAccessPermissions(HKEY hkey, PSECURITY_DESCRIPTOR pSD) {   BOOL bResult = FALSE;   DWORD dwLen = GetSecurityDescriptorLength(pSD);   LONG lResult;   lResult = RegSetValueExA(hkey,        "AccessPermission",        0,        REG_BINARY,        (BYTE*)pSD,        dwLen);   if (lResult != ERROR_SUCCESS) goto done;   bResult = TRUE; done:   return bResult; } [/CODE]

다음 코드는 SD 상위의 권한으로 무조건적으로 CoInitializeSecurity를 호출하는 방법을 보여줍니다.

[CODE] // Absolute SD values PSECURITY_DESCRIPTOR pAbsSD = NULL; DWORD AbsSdSize = 0; PACL  pAbsAcl = NULL; DWORD AbsAclSize = 0; PACL  pAbsSacl = NULL; DWORD AbsSaclSize = 0; PSID  pAbsOwner = NULL; DWORD AbsOwnerSize = 0; PSID  pAbsGroup = NULL; DWORD AbsGroupSize = 0;

MakeAbsoluteSD (   pSD,   pAbsSD,   &AbsSdSize,   pAbsAcl,   &AbsAclSize,   pAbsSacl,   &AbsSaclSize,   pAbsOwner,   &AbsOwnerSize,   pAbsGroup,   &AbsGroupSize ); if (ERROR_INSUFFICIENT_BUFFER == GetLastError()) {   pAbsSD = (PSECURITY_DESCRIPTOR)LocalAlloc(LMEM_FIXED, AbsSdSize);   pAbsAcl = (PACL)LocalAlloc(LMEM_FIXED, AbsAclSize);   pAbsSacl = (PACL)LocalAlloc(LMEM_FIXED, AbsSaclSize);   pAbsOwner = (PSID)LocalAlloc(LMEM_FIXED, AbsOwnerSize);   pAbsGroup = (PSID)LocalAlloc(LMEM_FIXED, AbsGroupSize); if ( ! (pAbsSD && pAbsAcl && pAbsSacl && pAbsOwner && pAbsGroup)) {    hr = E_OUTOFMEMORY;   goto Cleanup; } if ( ! MakeAbsoluteSD(        pSD,        pAbsSD,        &AbsSdSize,        pAbsAcl,        &AbsAclSize,        pAbsSacl,        &AbsSaclSize,        pAbsOwner,        &AbsOwnerSize,        pAbsGroup,        &AbsGroupSize        )) {      hr = HRESULT_FROM_WIN32(GetLastError());      goto Cleanup; } else {      hr = HRESULT_FROM_WIN32(GetLastError());      goto Cleanup; } // CoinitilizeSecurity 호출 [/CODE]

COM 권한 및 위임 접근 라벨(COM Permissions and Mandatory Access Labels)
Windows Vista에서 보안 상세서(security descriptors : SD)에 있는 위임 접근 라벨에 대한기본적인 내용을 소개하였습니다.라벨에서는 클라이언트가 COM 객체로 접근 실행할 수 있도록 지시하게 됩니다. 라벨에는 보안 명세서의 시스템 접근 제어 리스트(system access control list : SACL)내에 명시되어 있습니다. Windows Vista에서는 COM 자체적으로 SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP 라벨을 지원합니다. Windows Vista 이전 운영체제에서는 COM 권한 내의 SACLs들의 내용이 무시되었습니다.
Windows Vista에서는 dcomcnfg.exe가 COM 권한 내에서 더 이상 통합 레벨(IL) 변경을 지원하지 않습니다. 반드시 프로그렘 적으로 설정하게끔 되어 있습니다.
다음 예제 코드에서는 모든 낮은 IL 클라이언트에서 실행/활성화 요청을 할 수 있도록 라벨을 이용하여 COM 보안 명세서를 어떻게 생성하는지에 대해 나타내고 있습니다. 이렇게 하면, 일정한 IL을 가진 클라이언트에서 실행, 활성화 또는 호출에서 실패된 COM 서버를 쓸 수 있게 됩니다.통합 레벨(IL)에 대한 더 자세한 사항은 Understanding and Working in Protected Mode Internet Explorer 안에 있는 "Understanding Windows Vista's Integrity Mechanism" 섹션을 보시기 바랍니다.

[CODE] BOOL GetLaunchActPermissionsWithIL (SECURITY_DESCRIPTOR **ppSD) { // Allow World Local Launch/Activation permissions. Label the SD for LOW IL Execute UP   LPWSTR lpszSDDL = L"O:BAG:BAD:(A;;0xb;;;WD)S:(ML;;NX;;;LW)";   if (ConvertStringSecurityDescriptorToSecurityDescriptorW(lpszSDDL, SDDL_REVISION_1, (PSECURITY_DESCRIPTOR *)&pSD, NULL))   {        *ppSD = pSD;        return TRUE;   } } BOOL SetLaunchActPermissions(HKEY hkey, PSECURITY_DESCRIPTOR pSD) {   BOOL bResult = FALSE;   DWORD dwLen = GetSecurityDescriptorLength(pSD);   LONG lResult;   lResult = RegSetValueExA(hkey,        "LaunchPermission",        0,        REG_BINARY,        (BYTE*)pSD,        dwLen);   if (lResult != ERROR_SUCCESS) goto done;   bResult = TRUE; done:   return bResult; }; [/CODE]

CoCreateInstance 및 통합 레벨(IL)
CoCreateInstance의 기능은 Windows Vista에 이르러 낮은IL 클라이언트에서 기본적으로 COM 서버를 연결하는 것을 방지하게 끔 변경되었습니다. 서버는 반드시 SASL로 명시하여 연결해야 명확하게 연결되게 됩니다.CoCreateInstance의 변화된 사항은 다음과 같습니다.

  • COM 서버 프로세스를 실행할 때, 서버 프로세스 토큰 내 IL이 클라이언트 또는 서버 토큰 IL으로 설정되어 있어야 하며, 무엇보다 IL이 낮아야 합니다.
  • 기본적으로, COM은 어떠한 COM 서버의 인스탄스를 실행하기 위해 낮은 IL 클라이언트이 연결하는 작업 자체를 배제합니다.연결을 허용하려면, COM 서버의 실행/활성화 보안 명세서(Launch/Activation security descriptor)가 낮은 IL 라벨 상에 명시되어 있는 SACL이 담겨 있어야 합니다.(이와 같은 보안 명세서를 생성하기 위한 예제 코드를 이전 섹션에서 보실 수 있습니다.)

권한 상승된 서버 및 ROT 등록
만일 COM 서버에서 실행 객체 테이블(Running Object Table : ROT)에 등록하는 경우나 기타 클라이언트 상에서 등록을 할 수 있도록 하려면, 제일 먼저 을 원하는 경우 ROTFLAGS_ALLOWANYCLIENT 플래그를 사용하셔야 합니다. 단, '활성자로써 활성화(Activate as Activator)' 형태의 COM 서버에서는 ROTFLAGS_ALLOWANYCLIENT를 명시해줄 수 없는데 그 이유는 DCOM 서비스 컨트롤 관리자(DCOMSCM)에서 강제적으로 이 플래그에 대한 속임수 체크를 수행하기 때문입니다. 그러므로 Windows Vista에서는 COM에서 새로운 레지스트리 항목에 대한 지원을 추가해야 합니다. 새로운 레지스트리 항목은 클라이언트에 가능하게 만들어주는 ROT 등록을 명시적으로 할 수 있도록 서버를 허용하는 항목입니다.

HKEY_LOCAL_MACHINE\Software\Classes\AppID\

{ APPID }

REG_DWORD_ROTFlags

단 한개의 이 항목에 대해 적용가능한 값은 다음과 같습니다.

[CODE] ROTREGFLAGS_ALLOWANYCLIENT 0x1 [/CODE]

이 항목은 HKEY_LOCAL_MACHINE 영역에 있어야 합니다.
그리고 ROTFLAGS_ALLOWANYCLIENT 로 RunAs server가 제공되는 기능을 '활성자로써 활성화(Activate as Activator)'와 동일하게 동작하기 위한 사항입니다.

추가적인 사항
Reference
BIND_OPTS3

기타 자료
Understanding and Working in Protected Mode Internet Explorer



728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

가상 회사 Litware Inc. 만들기.

잡글 2006. 11. 30. 10:55
이번에 SharePoint 2007(MOSS)를 테스트 겸 공부 겸 하기 위해서 가상의 회사를 만들어봤다. 사실 이 회사의 이름은 Microsoft 의 MOSS Lab안에 있는 LITWARE를 그대로 가져왔다. 하지만, 그 구성원은 전부 영어 이름. 게다가, 그 Active Directory 내 구성원이 누가 누구인지 전혀 모른다.

소설이나, 만화등에서 종종 보게 되는 문구인 "실제 인물, 회사, 지명과 일체 관계 없습니다."를 먼저 명기할 필요가 있다. 사실 저기 적힌 이름은 내 멋대로 지어낸 이름인데다가, 스스로 저 이름일 때 과연 자신은 어떤 아이디로 만들까 해서 탄생한 것이다.
이 내용을 가지고 Active Directory의 OU로 만들고 Exchnage까지 꾸렸다.
이렇게 꾸민 이유는 이번 MOSS안에 내장된 결제 시스템에 관한 부분 까지 보고 싶기 때문에 만들었다.

슬슬 준비 되는 대로 위의 계정 대로 테스트를 해봐야 겠다.
그런데 만들어 놓고 보니.. 생각보다 멋지다는 생각이 -_-;;
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

대하드라마 요시츠네(義經)

잡글 2006. 11. 24. 15:13

일본 역사 중 천황을 중심으로 두개의 군사 핵심이 두개가 있었다.
하나는 겐지 그리고 다른 하나는 헤이케.
그 중 겐지에서 천황을 뒤업기 위해 반란을 했고, 그 반란을 헤이케의 타이라노 키요모리가
진압에 성공한다. 이 때 겐지의 중심이였던 요시토모가 죽고 그의 아들들은 대부분 죽게 된다. 그 중  적자, 요리토모 그리고 서자인 이마와카, 오토와카, 우시와카(요시츠네의 아명)만이 간신히 살아 남는다. 모두 죽을 운명이였지만, 요시토모의 애첩인 토키와의 애절한 간청과 키요모리 의모의 고집으로 그 4명은 살아남게 된다. 그 중 요리토모는 동부(현재 도쿄현 근처)에 유배를 이마와카와 오토와카는 절로 가게 되고, 그 중 우시와카만, 간난아이로 토키와와 함께 수도에 남게 된다.

요시츠네는 어릴때는 헤이케 키요모리가 아버지라고 생각할 정도로 헤이케의 보살핌 속에 살게 된다. 그가 기나긴 여정과 전투 중에도 바로 이 헤이케를 잊지못하는 정을 가지게 된 성장 과정이였다. 또한 키요모리도 남달은 애정을 이 요시츠네에게 쏟아붑는다. 하지만, 요시츠네가 7살이 되자 헤이케 가문내의 많은 사람들은 그를 배척하게 되었고, 결국 키요모리도 요시츠네를 절로 보내 불가에 입문하게 만든다. 그러나 요시츠네는 불가로 가지 않고, 끝까지 버티며 지내게 된다. 그가 자라 나이를 먹고 그 때 만난 음양사 호겐을 만나 무술과 다양한 기술들을 배우고, 종종 수도를 내려오게 되었는데, 이 때 헤이케의 토키코에게 발각되고 결국 그는 중이되거나 수도를 도망가야 되는 사태까지 이르게 된다. 이 때 결국 수도를 빠져나가기로 결심하며, 정토(고요하고 안정된 장소)의 땅 히라이즈미로 가게 된다. 여기서 관복(어른으로써 갓을 쓰는 의식)을 스스로 하여 이 때 아명인 우시와카, 챠오오를 버리고 요시츠네로 개명하게 된다. 그리고 히라이즈미에서 더 넓은 시야와 행복의 땅에서 그의 곧은 성품으로 많은 사람들을 감동시키고 그 안에서 살게 된다. 이 때 그의 이복형인 요리토모가 거병을 하게 되고 그 뒤를 따라 가게 된다. 이 때 그의 화려한 일대기가 시작하게 되었다.

헤이케 평정 동안, 그는 다양한 전투를 하며 그의 화려한 전술과 무용을 자랑하게 되는데, 이 또한 그의 충성스런 6명의 가신을 중심으로 더욱더 화려하고 예상 밖의 결과를 항상 가져오게 되었다. 더욱이 당시에서는 생각도 못한 파격적인 전술을 구사하여 다른 이들의 시셈도 가져오게 되었다.

그러나 결국 그 끝은 요리토모와 고시라카와 법황의 사이에 끼어 암투 속에서 서서히 그를 갉아 먹게 되고, 결국 요리토모가 고시라카와 법황을 누르게 되자 요리토모가 요청한 요시츠네 추토(반란 등으로 인해 처벌하는 것)가 시행되게 된다.
결국 이 추토 기간 동안 요시츠네는 몰락하며 쫒기게 되고 결국 죽게 된다.

긴 대하 드라마이고, 이 드라마 역시 가네코 나리코라는 작가에 의해 탄생된 내용이다. 그래서 정확한 역사적 배경이나 그의 진실된 모습은 잘 모르겠다. 하지만, 일본이라는 국가의 군국주의 탄생의 시작들을 볼 수 있었다. 아마도, 우리나라의 고려 때 무신들 중에 요리토모라는 인물격의 사람이 있었다면, 분명 이와 같지 않았을까? 다행이라는 생각과 함께 아쉽다는 생각이 드는건 나만일까....

무조건 일본 원숭이 쪽바리로 내치기 보다 한번은 이런 일본인들의 시각을 바라보는 것도 좋을 것 같다. - 하지만 역시 일본 사람들의 이름은 익히기도 어렵고 보기도 어렵다 -

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

About Office SharePoint 2007

잡글 2006. 11. 24. 10:06

문서 공유 솔루션으로 제시된 Windows SharePoint 와 SharePoint Portal 이라는 MS의 제품 군이 있다. 이 제품의 주요한 목적은 MS Office에서 만들어진 문서들을 웹 위에서 공유할 수 있도록 하는 것이다. 이 제품 군이 완성되서 하나의 제품/솔루션으로 제시된지는 오래되었지만, 사실 이 화려한 광고 문구에 비해 한계점이 너무 많았다.
MS Office 에서 생산된 문서의 공유는 우수했을지는 모르겠지만, 보안 상으로 문서를 걸러내는 것도 불가능했고, 인트라넷에서 활용할 수 있을 만큼 훌륭한 웹 페이지를 제공하지도 못했다. 물론 웹파트라는 단위로 나름대로 동적으로 꾸밀 수 있지만, 이 부분은 관리자가 통합된 형태로 변경하더라도 그 웹파트의 기능이 너무도 한계가 많았다. 프로그래머 레벨로 들어가더라도, SharePoint 컴포넌트 접근이 너무 까탈 스러웠으며, 모든 웹페이지의 메타 데이터로 DB에 저장하다 보니 도리어 복잡도만 늘어 손쉽게 접근이 불가능했다.

이번 SharePoint 2007에서는 위의 문제점들을 개선했으며, 많은 부분을 재디자인 했다.
특히 .NET Framework 2.0에 통합하면서 Windows SharePoint가 그 Framework 내에 포함되게 되었다. 그래서 다양한 부분의 기능이 추가됨과 동시 다양한 설계적인 문제점을 개선할 수 있게 되었다.
일단 제일 나아진 점은 역시 문서별 권한 설정이라고 생각한다. 한두 사람이나 한개의 팀정도의 작은 규모에서는 문서가 아무렇게나 등재되도 상관 없지만, 회사 전체에서 이용한다면, 이 부분은 상당한 강점이 될 수 있다. 대외비 문서나, 개인 문서들이 올라가더라도, 각 문서들의 권한 설정을 하게 되면, 특별히 문서 보안 솔루션 없이도 충분히 보호가 된다는 것이다.
두번째 나아진점은 Workflow 지원이다. 물론 과거에도 BizTalk등을 이용해도 가능한 부분이였지만, 일단 SharePoint와의 연계가 어려울 뿐더러 BizTalk를 이용한 솔루션 제작이나 유지보수가 무척이나 어려웠다. 그러나 .NET Framework 3.0 자체에서 지원되는 내용을 그대로 이용할 수 있어, 어느정도 레벨의 Workflow를 제작할 수 있게 되었다. 이를 통해 만들 수 있는 단순한 예로 문서 결제와 같은 기능을 들수 있다.
세번째 나아진점은 개인화 기능이다. 일단 예전과는 다르게 폼 기반의 로그인/로그 아웃을 지원하게 되어 개인별 독자적인 화면을 만들 수 있게 되었다. 앞서 단점으로 제시했던 화면 메타데이터 화가 여기서는 나름대로 장점으로 나타나게 되었다. 그래서 화면들을 별도의 페이지로 만들지 않아도, 개별적으로 해당 내용을 편집 구성할 수 있으며, 자동으로 저장된다. 또한 언어별 별도 페이지 구성할 때도 디자인 요소 변경 없이 문서, 이미지 개체를 메타 데이터 화 해서 별개로 저장 할 수 있게 되었다.

새로운 버전이 나오면 당연하게 개선되고 더 나은 기능을 보여주는 것은 당연하다고 생각된다. 특히나 MS 제품들은 예전 제품을 개선하기 위해 ISP에서 개발된 사항들을 중에 선택하여 품기 때문에 더 나은 형태가 나오게 되었다고 생각한다.
이번에도 아직은 RTM이 나오지는 않은 상태지만(조만간 나올듯 싶다.) 나름대로 기대된다.
단지....현재 나온 상태를 기준으로 다소 아쉬운 부분이 한가지 있었다.
특히 AJAX를 이용한 Refresh 없는 디자인이였으면 참 좋았을 텐데 그리 구성되지 않았다. 아직은 ISP에서 할일이 있겠다라고 생각해 본다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

Programing의 새로운 파라다임.

잡글 2006. 11. 23. 13:11

과거 Computer를 가지고 프로그래밍을 하는 것은 상당히 고난이도의 작업이였다.
먼 과거도 아닌 대략 20년 전까지만 해도 그런 인식이 강했었다.
그러나, 지금 정보화 산업이라는 발판으로 인해 그런 느낌은 많이 사라져 있다.
많은 사람들이 이젠 컴퓨터로 정보를 얻고, 생산하며, 공유하고 있다.
특히, 사내 자원 관리 같은 분야에서는 이 부분이 너무도 중요하게
있는 부분이다. 단순하며 반복적인 작업을 알아서 처리해 주고, 문서 남발로
보관하기 힘든 종이 뭉턱이를 없애며, 수많은 자원 정보를 간단하게 오랫동안
보관해 주며, 동시에 그 안에서 다양한 업무 지식을 보다 빠르고 확실하게 찾아주고 있다.

그러나, 그 일면 컴퓨터로 하는 작업 중, 이 프로그래밍이 이라는 분야에 대해서는 아직은 전문가의 성역(?)이 되어 있는 것이 사실이다. 그래서 현재 사내 업무/자원 관리 시스템 구축은 여전히 프로그래머들이 만들며, 그 해당 업무의 전문가들은 단지 요구사항과 불평 사항만을 말하게끔 역할이 지어져 있다. 바로 이 역할 부분이 바뀌게 될 것 같다는 것이다.
예전 교내 벤처에서 교수님이 말한 사용자 중심 UI, 즉 개인화 아이디어나, 그 이후 자리를 옮겨 진행했던 회사에서 사장님이 생각했던 일반 사용자가 프로그래밍을 배워 자신이 원하는 단순한 기능을 하는 무언가를 만들어 내는 것, 그리고 내 후배가 다니는 회사의 사장님이 생각하는 업무 전문가들이 보다 쉽게 접근 할 수 있는 그런 업무 전문가만이 다루는 프로그래밍 기능은 바로 이런 맥락으로 따라갈 것이라 생각된다.
수많은 개인화와 기능들의 단순화 들은 이제 프로그래머들이 프로그램을 짜는 것이 아닌 해당 업무 전문가가 프로그래밍을 할 수 있는 그런 세상을 점점 앞당긴다는 것이다.

자, 나도 프로그래밍으로 밥을 먹는 사람의 입장으로 위와 같은 밥그릇 없애기 작전에 동의를 하냐고 묻는다면... 글쎄라는 유보의 입장이다. 사실 위의 파라다임 대로 이루워진 프로그램을 만들기도 힘들 뿐더러, 그 만큼 해당 업무 당당자의 일이 늘어난다는 것이다. 그것은 지울 수 없는 사실. 하지만, 분명한 것은 모든 프로그램들이 점점 위의 방향대로 흘러간다는 것. 그러기 때문에, 이젠 프로그래머들도 변신해야 되며, 나 역시 그러리라 생각된다.

이젠 프로그래머는 더 이상 잡스런 기술의 난잡함 속에 묻혀서는 안된다 싶다. 이젠 그 깊은 안쪽으로 돌아가서, 업무 전담 전문가들이 이용할 수 있는 컴포넌트/서비스를 만들 때라고 생각한다. 그래서 그들이 원하는 형태로 개인화를 할 수 있도록 도와주며, 그 안에서 계속적인 업그레이드를 해야 한다 생각한다.
아마도.... 이렇게 해야 하는 일은... 먼 미래가 아닌 바로 지금일지도 모르겠다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

Windows Vista RTM에 이어 Office 2007 RTM이 나왔었구나..

잡글 2006. 11. 17. 15:30

일전 ZDnet을 통해서 Windows Vista RTM이 나왔다는 것을 알고 있었는데,
MSDN의 Subscription에 드디어 등재되었다.
그래서 일단 Vista 확보... 라고 옆을 보니, MS Office 2007도 RTM이 나왔다.

생각보다 빠른 진전이라고 생각된다. 난 한 12월 정도에 출시할 줄 알았는데.
물론 RTM이기 때문에 일부 파트너 및 OEM 그리고 기업에만 공개된 버전이기
때문에, 실제 상자 만들고 그 상자로 판매되는 Retail 버전은 조금 시간이
걸릴 것이다.

아직 Vista는 한글판이 없었지만, Office는 어느새 한글판까지 나왔다.
일단 깔고 설치해보니, 나름대로 괜찮은 것 같다.
확실히 예전 버전에 비해서 많이 좋아진것 같기도 하다.
아직은 사용중이지만, 조금더 사용해 봐야 얼마나 좋은지 알 수 있을 것 같다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

현재 내 ICQ 안에는...

잡글 2006. 11. 7. 13:07
어제 간신히 알아낸 내 ICQ 번호로 접속을 했다.
사실 대구 동상이 자기는 ICQ만 한다고 해서..
낼름 깔아서 접속했더니...
어제 갑자기 메시지와 함께 추가 했던 중국 언니만 떨렁하니 있다...(솔직히 언니는 아니다.. 나보다 마이 어리긴 하드라...)

대구 동상도 동상이지만..그간에 ICQ를 통해 만났던 친구들이 모두 Offline이 되었다.
사실 MSN으로 이주한 친구들이 대부분인지라.. 이젠 ICQ를 통해 대화를 더 이상 나누지도 않지만..

조금은 아쉽다는 느낌도.. 든다.
문득...예전에 만든 Icq76이라는 홈피도 가봤다.
아직은 동작하는데.. 무언가.. 조금은
많이 낡아 버렸다는 느낌이 든다.

나중에 시간 되면.. 한번 전부 손을 봐야 할 거 같다. 내 기록들이나.. 기타 등등 다양한 것들을 정리할 때 이 ICQ76 도 함 정리를 해야 겠다.

어차피 계정도 하나 쓸데 없이 만든것도 있고..
거기다가 모조리 옮겨서 정리나 해야겠다.
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

내 ICQ 번호

잡글 2006. 11. 6. 10:19

계속 잊어 버리고 있다가 간신히 찾았다.
예전 홈페이지 기록에서 뒤적 뒤적.

Hind Hildebrand, HyungJin Kim 등등 다양하게 Google을 통해 검색해 보았건만
나오지 않아 결국 홈페이지 뒤적이니 나온다.
번호는 49672302.

드디어.. ICQ를

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

  • «
  • 1
  • »
250x250

블로그 내에 소스 코드 삽입 이사온 기념 스킨도... RSS 전문 기능 비활성화 관련. 스킨 바꾸어 보았습니다. 서버 파일 정리 좀 했습니다.

«   2006/11   »
일 월 화 수 목 금 토
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

me2photo Buscuit Visual Studio 비스킷 SharePoint Azure 개발환경 moss 수 Google Apps Engine Tutorial 오류 지름신 매뉴얼 java 블로그 좀 것 e-book me2sms 협업 MOSS 2007 me2dayzm windows 인터파크 twi2me 불만 친구 WSS 2010

  • Total :
  • Today :
  • Yesterday :

Copyright © 2015-2025 Socialdev. All Rights Reserved.

Copyright © 2015-2025 Socialdev. All Rights Reserved.

티스토리툴바