2016년 11월 30일 수요일

Supreme Court Explicitly Recognizes Fixed-Term Employee's Expectation of Conversion to Regular Employment

We write about a recent Supreme Court case in which the Court explicitly recognized, for the first time, that a fixed-term employee who was hired after the enactment of the Act on Protection of Fixed-Term and Part-Time Employees (the "Act") had a reasonable expectation and right to convert their fixed-term employment contract into a regular indefinite term employment contract, where certain conditions are met (such as evidence of an intent to renew by the parties). (Supreme Court Decision 2014 Du 45765 rendered on November 10, 2016), (hereinafter the "Supreme Court Case").

The Significance of this Case

For fixed-term contracts that were entered into prior to the introduction of the Act, few questioned that employees working under fixed-term employment contracts had reasonable expectations that their contracts would be renewed. (Supreme Court Decision 2011 Du 12528 rendered on February 13, 2014).

With regard to post-Act fixed-term contracts, however, the lower courts have been less likely to acknowledge a fixed-term employee's reasonable expectation of renewal of their contract primarily because the Act introduced a two-year term limit on fixed-term employment contracts, and employers and employees could reasonably expect that the employment relationship would conclude at the end of that two-year limit.

In the Supreme Court Case, however, the Court held that a fixed-term employee's reasonable expectation for contract renewal is not restricted, even though they had a post-Act fixed term employment contract, because "the rules under the Act are established fundamentally for the purpose of preventing the abuse of fixed-term contracts and assuring employees' employment status." Further, the Court ruled that, in light of Article 5 of the Act (and other statutes) which provides for preferential employment of fixed-term employees performing the same or similar jobs or duties as regular employees, a fixed-term employee would have a reasonable expectation of conversion to an employment agreement with an indefinite term ("Expectation of Conversion to Regular Employment") if certain conditions are met.

Below is the key evidence behind the Court's ruling that the Plaintiff fixed-term employee had an Expectation of Conversion to Regular Employment:

§ The employee's employment contract stated that "this contract may be renewed one month prior to the expiration of the contract,"
§ At the time the fixed-term contract was made, the parties intended to convert it into a regular employment contract upon evaluation at the end of the fixed-term,
§ The fixed-term employee performed the same tasks and duties as other regular employees, and the company repeatedly told its fixed-term employees that they would be converted to regular employees unless there were special circumstances,
§ The company in fact had converted all of its other fixed-term employees to regular employees in the past, and
§ The company evaluated the Plaintiff fixed-term employee's performance a month before his employment contract was set to expire, to provide an opportunity to convert to regular employment.

In this case, the Court determined that the company's performance evaluation of the Plaintiff fixed-term employee was unfair; that the company failed to establish just cause to lawfully terminate his employment contract; and therefore, that the he was wrongfully terminated.

The Implication of this Case

Based on the recent Supreme Court Case, we believe that fixed-term employees are more likely to have Expectations of Conversion to Regular Employment if their duties are the same or similar to regular employees, and if a company has official performance evaluation procedures that are applied when deciding whether to convert fixed-term employees to regular employees. If your business already has evaluation procedures in place for fixed-term employees to assess whether they are qualified to convert to regular employment, we recommend that you ensure that the procedures are applied in a reasonable and fair manner.

Also related to fixed-term employees, please note that, according to a recent lower court decision (Seoul Southern District Court Case 2014 GaHap 3505 rendered on June 10, 2016), discriminating against employees on the grounds of their employment type (e.g., regular versus fixed-term employment) may constitute "discrimination based on social status" prohibited under the Labor Standards Act. Accordingly, when determining the working terms and conditions of a fixed-term employee whose employment was converted to regular employment, employers must carefully review related policies, programs, and practices so that the new regular employees are not illegally discriminated against in terms of their working terms and conditions as compared to those of existing regular employees.

기간제법 시행 이후 정규직 전환기대권을 인정한 최초의 대법원 판례

기간제 및 단시간 근로자 보호 등에 관한 법률 (이하 "기간제법") 시행 이후에 체결된 기간제 근로계약에 관하여 근로자의 갱신기대권, 나아가 정규직 전환기대권을 인정한 최초의 대법원 판례가 선고되었기에 소개해 드립니다(대법원 2016.11.10. 선고 2014두45765 판결, 이하 "본건 판결").

본 건 판결의 의의

기간제법이 시행된 2007. 7. 1. 이전에 체결된 기간제 근로계약의 경우, 법 시행 전에 이미 형성된 기간제 근로자의 갱신 기대권이 법 시행 이후에도 계속 인정된다는 점에 관해서 큰 논란의 여지가 없었습니다(대법원 2014. 2. 13. 선고 2011두12528판결).

그러나 기간제법 시행 이후에 체결된 기간제 근로계약의 경우, 하급심 판례는 사용자와 근로자가 "2년 계약기간 만료 후 퇴직"을 예정한 경우가 많다는 이유로 갱신기대권을 좁게 인정하는 경향이 있었습니다.

반면 본건 판결은 "기간제법 규정들의 입법 취지가 기본적으로 기간제 근로계약의 남용을 방지함으로써 근로자의 지위를 보장하려는 데에 있는 점"을 고려하여, 기간제법 시행 이후에 체결된 기간제 근로계약의 경우에도 기간제 근로자의 갱신에 대한 정당한 기대권 형성이 제한되지 않는다고 판시하였습니다. 나아가 본건 판결은, 동종 또는 유사한 업무에 종사하는 기간제 근로자를 정규직으로 우선 고용하도록 하는 기간제법 규정(제5조) 등을 감안하면, 일정한 요건을 갖춘 경우 기간제 근로자에게 기간의 정함이 없는 근로자로 전환될 수 있으리라는 정당한 기대권("정규직 전환기대권")이 인정될 수 있다고 판시하였습니다.

본건 판결에서 대법원이 기간제 근로자의 정규직 전환기대권을 인정한 근거는 다음과 같습니다.
§ 근로계약서에 "근로계약 만료 1개월 전에 재계약할 수 있다"는 내용이 기재되어 있는 점
§ 애초에 기간제 근로자로 고용한 취지가 기간제 근로계약 기간 만료 무렵 인사평가를 거쳐 정규직 근로자로 전환하기 위한 것이었던 점
§ 기간제 근로자가 정규직 근로자와 동일한 업무를 수행하였고, 회사도 기간제 근로자들에게 특별한 사정이 없는 한 정규직으로 채용될 것이라고 지속적으로 말해 온 점
§ 회사는 과거 다른 기간제 근로자들을 모두 정규직으로 전환하였고, 참가인에게도 정규직 승격의 기회를 주기 위해 계약만료일 1개월 전에 인사평가를 실시하였던 점

구체적으로, 대법원은 회사가 참가인에 대해 실시한 인사평가가 공정하다고 볼 수 없고, 따라서 그에 따른 기간제 근로계약기간 종료 통보는 정당한 이유가 없어 부당해고에 해당한다고 판단하였습니다.

본 건 판결의 시사점

기간제 근로자의 담당 업무가 정규직 근로자와 동일 내지 유사하고 정규직으로 전환하기 위한 공식 인사평가 절차가 존재하는 경우, 기간제 근로자의 정규직 전환기대권이 인정될 가능성이 높아질 것으로 판단됩니다. 따라서 기간제 근로자의 정규직 전환을 위한 인사평가 절차가 합리적이고 공정하게 운영되도록 주의를 기울일 필요가 있겠습니다.

한편 최근 하급심 판결(서울남부지방법원 2016. 6. 10. 선고 2014가합3505 판결)에 따르면 고용형태에 따른 차별 역시 근로기준법이 금지하는 "사회적 신분에 따른 차별"에 해당할 수 있습니다. 따라서 정규직으로 전환되는 기간제 근로자(소위 무기계약직)의 근로조건을 결정함에 있어, 일반 정규직 근로자에 비해 불합리한 차별이 발생하지 않도록 관련 제도, 규정 및 관행을 점검 및 개선할 필요가 있겠습니다.

감사합니다.

Safety Management Act on Electronic and Industrial Products

In an effort to consolidate and manage safety measures for electronic products and industrial products, the Safety Management Act on Electronic Products and the Quality Control and Safety Management of Industrial Products Act will be consolidated under the Safety Management Act on Electronic and Industrial Products (the "Consolidated Act")) (Act No. 13859 promulgated on January 27, 2016). The Consolidated Act will go into effect on January 28, 2017.

The main features of the Consolidated Act are as follows:

1. Consolidation of Safety Management (Articles 5, 15 and 23 of the Consolidated Act)

The Safety Management Act on Electronic Products provides measures for safety certification, safety confirmation and measures to verify the appropriateness of a distributer. The Quality Control and Safety Management of Industrial Products Act includes quality management, safety certification, voluntary safety confirmation by a distributer, and safety quality labeling and packaging for children's safety. It has been criticized that the two laws created confusion to the public that needed to confirm the safety of a product and hindered the efficiency of the safety management procedures.

Under the Consolidated Act, safety management measures have been consolidated to include safety certification, safety confirmation and measures to verify the appropriateness of a distributer, and the quality control previously governed under the Quality Control and Safety Management of Industrial Products Act shall be managed separately as of January 28, 2017 with the Industry Safety Act.

For your reference, reports filed with the relevant administrative agencies in accordance with the individual laws in the past shall be deemed to be in accordance with the Consolidated Act, and certifications previously obtained under the previous laws are not required to obtain new certifications pursuant to the Consolidated Act.

2. Consolidation of inspection procedures and timeline (Article 7 of the Consolidated Act)

In the past, products that had previously obtained safety certifications(e.g., electronic products), were required to obtain regular inspections more than once every year from a safety inspection institution, and if the results of the regular inspection were acceptable, an exemption from all or part of the regulation inspection may be granted. On the other hand, for industrial products that previous obtained safety certifications, regular inspections were conducted once every 2 years, provided that under special circumstances, additional inspections could be conducted. Based on these results, the period for regular inspections was different and it was unclear when additional inspections were necessary.

Under the Consolidated Act, all products that require safety certification shall be inspected regularly, once every 2 years. Additional inspections will no longer be necessary. Products that have completed regular inspections prior to the effective date of the Consolidated Act shall be deemed to have completed regular inspections under Article 7.1 of the amended regulations.

3.Obligation to disclose information for online sales (Articles 9, 18 and 25 of the Consolidated Act)

Anyone who intends to sell, lease, sell as a broker, buy by proxy or import by proxy products that require safety certification, safety confirmation, or verification regarding the appropriateness of a distributer, must disclose information regarding the certification to ensure that the safety of the products have been verified regularly. Distributors that violate these obligations shall be subject to administrative fines of not more than KRW 5,000,000.

4. New provision to regulate invalidity of reporting safety confirmation (Article 20 of the Consolidated Act)

Before the Consolidated Act, it was only possible to issue a correction order, or prohibit the use of safety confirmation labels on safety certification notices that were made by fraudulent or wrongful means. However, under the Consolidated Act, additional measures such as invalidating the safety confirmation will become available.

5. New reporting requirements to verify the appropriateness of a distributer (Article 23 of the Consolidated Act)

Prior to the Consolidated Act, it was sufficient for a manufacturer or importer (which was required to verify the appropriateness of the distributor of the product) to conduct an inspection internally or through a third party to confirm the product had met safety standards. Under the Consolidated Act, for electronic products (not industrial products), verification of safety standards must be reported to the Ministry of Trade Industry and Energy. Furthermore, distributers that violate these obligations may be subject to administrative fines of not more than KRW 5,000,000.

In addition to the above, there are other amendments in the Consolidated Act including (i) an exemption for certification of products manufactured or imported on a one-time basis (Article 6 of the Consolidated Act) and (ii) abolishment of the expiration period of safety confirmation.

The Ministry of Trade Industry and Energy will announce the Proposed Enforcement Decree to the Consolidated Act as well as the Proposed Enforcement Regulations to the Consolidated Act by November 25, 2016. According to the proposed announcements of the Enforcement Decree, it is expected to include clarification on types of models for industrial products, improvements to the exemptions available for KC Certification of KS certified products, and new provisions regarding regular inspections of importers subject to safety certification. We will inform you once the Enforcement Decree to the Consolidated Act as well as the Enforcement Regulations to the Consolidated Act have been announced.

전기용품 및 생활용품 안전관리법 제정 안내

현재 별개 법률로 운영되고 있는 전기용품과 공산품의 안전관리제도를 통일적이고 종합적으로 운영하여 전기용품과 공산품의 위해로부터 국민의 생명ㆍ신체 및 재산을 보호하기 위하여 「전기용품안전 관리법」과 「품질경영 및 공산품안전관리법」을 통합한 「전기용품 및 생활용품 안전관리법」이 제정(법률 제13859호, 2016. 1. 27. 공포)되어 2017. 1. 28. 시행을 앞두고 있습니다.
전기용품 및 생활용품 안전관리법(이하 ‘통합법’이라 함)의 주요 내용은 아래와 같습니다.

1. 안전관리제도의 통합 (통합법 제5조, 제15조, 제23조)

기존 전기용품안전관리법에는 안전인증, 안전확인, 공급자적합성확인제도를 두고 있었고, 품질경영 및 공산품안전관리법에는 품질경영, 안전인증, 자율안전확인, 안전품질표시, 어린이보호포장에 관한 제도를 운용하였으나 국민에게 제품의 안전성 확인에 대해 혼란을 주고 안전관리제도의 효율성을 저해한다는 문제점이 지적되었습니다.
이에 통합법에서는 안전인증, 안전확인, 공급자적합성확인, 어린이보호포장으로 안전관리제도를 통합하였으며, 기존 품질경영 및 공산품안전관리법이 규정하던 품질경영과 관련된 부분은 2017. 1. 28.부터 산업표준화법으로 이관되어 별도 관리될 예정입니다.
참고로, 종전 개별 법률에 따라 행정기관에 대하여 한 신고 등은 통합법에 따라 한 것으로 간주되므로, 종전법에 따라 이미 인증을 받으신 제품에 대해서는 통합법에 따라 새로운 인증을 받으실 필요는 없습니다.

2. 안전인증을 받은 제품의 검사 종류 통일 및 검사 주기의 완화 (통합법 제7조)

종래에는 안전인증을 받은 제품의 안전성 유지를 위하여 전기용품은 안전인증기관이 매년 1회 이상 정기검사를 실시하되, 정기검사의 결과가 우수한 경우 정기검사의 전부 또는 일부를 면제할 수 있도록 하였습니다. 반면에 안전인증을 받은 종래의 공산품은 2년에 1회 정기검사를 실시하되, 특별한 사정이 있는 경우에는 수시검사를 실시할 수 있도록 하였습니다. 그 결과 제품에 따라 정기검사의 주기가 다르고 수시검사의 사유가 명확하지 아니하여 제조자 등의 영업활동에 부담을 주는 문제점이 있었습니다.
이에 통합법은 안전인증대상제품 모두 2년에 1회 정기검사(안전인증대상제품, 제조설비, 검사설비, 기술능력)만을 실시하도록 하고 수시검사를 폐지하였습니다. 이를 통해 안전인증을 받은 안전인증제품에 대한 검사를 통일하고 단순화하여 제조자 등의 영업활동에 대한 불확실성 및 부담이 완화되었습니다.
한편, 경과조치에 따라, 통합법 시행 전에 이미 정기검사를 받은 경우에는 통합법 제7조 제1항의 개정규정에 따라 정기검사를 받은 것으로 간주됩니다.

3. 인터넷을 통한 판매 등에 대한 정보 게시의무 신설 (통합법 제9조, 제18조 및 제25조)

안전인증대상제품, 안전확인대상제품 및 공급자적합성확인대상제품을 인터넷을 통하여 판매ㆍ대여ㆍ판매중개ㆍ구매대행 또는 수입대행을 하려는 판매업자 등은 안전인증 등의 관련 정보를 소비자가 알 수 있도록 인터넷 홈페이지에 게시하도록 하여 정상적으로 안전이 확인된 제품만이 유통되고 소비되도록 하였습니다. 또한, 이러한 의무를 위반한 판매업자 등에 대해 500만원 이하의 과태료를 부과할 수 있도록 하였습니다.

4.안전확인신고의 효력상실 규정 신설 (통합법 제20조)

종래에는 거짓이나 부정한 방법으로 안전확인신고를 한 경우 안전확인표시 등의 사용금지 조치 또는 개선명령만을 할 수 있으나, 통합법에서는 추가로 안전확인신고의 효력을 상실시킴으로써 안전확인대상제품의 사후관리를 강화하였습니다.

5.공급자적합성확인대상전기용품에 대한 신고제도 도입 (통합법 제23조)

종래에 공급자적합성확인대상제품의 제조업자 또는 수입업자는 공급자적합성확인대상제품의 제품시험을 실시하거나 제3자에게 시험을 의뢰하여 해당 제품이 안전기준에 적합한 것임을 스스로 확인하면 충분하였으나, 통합법에서는 사고 발생의 경우 피해 정도가 큰 공급자적합성확인대상 전기용품에 한하여(생활용품은 제외) 안전기준에 적합한 것임을 확인한 내용을 산업통상자원부장관에게 신고하도록 하여 안전성 확인 및 유지를 위한 감독을 강화하였습니다. 또한, 이러한 의무를 위반한 판매업자 등에 대해 500만원 이하의 과태료를 부과할 수 있도록 하였습니다.

위 내용 이외에도, 통합법에는 (i) 안전인증대상제품을 일회성으로 수입하거나 생산하는 경우 인증 면제가 가능하도록 하였으며(통합법 제6조), (ii) 안전확인의 유효기간도 폐지하는 등 다양한 개정이 이루어졌습니다. 산업통상자원부는 2016년 11월 25일까지 통합법의 시행령(안)과 시행규칙(안)에 대한 입법예고를 하고 있습니다. 입법예고안에 따르면, 생활용품 모델구분의 명확화, KS인증제품의 KC인증 면제제도 개선, 안전인증의 주체가 된 수입업자의 정기검사 조항 신설 등 내용이 포함되어 있으며 조만간 확정될 것으로 예상됩니다. 추후 통합법 시행령과 시행규칙이 확정되면 다시 안내하여 드리도록 하겠습니다.

감사합니다.

2016년 11월 23일 수요일

궐위 및 탄핵에 관한 헌법 및 관계 법률(국회법, 헌법재판소법) 규정

□ 궐위선거에 관한 헌법 규정

 

68

  ② 대통령이 궐위된 때 또는 대통령 당선자가 사망하거나 판결 기타의 사유로 그 자격을 상실한 때에는 60일 이내에 후임자를 선거한다.

 

71조 대통령이 궐위되거나 사고로 인하여 직무를 수행할 수 없을 때에는 국무총리법률이 정한 국무위원의 순서로 그 권한을 대행한다.

 

□ 탄핵에 관한 헌법 규정

 

65 ① 대통령·국무총리·국무위원·행정각부의 장·헌법재판소 재판관·법관·중앙선거관리위원회 위원·감사원장·감사위원 기타 법률이 정한 공무원이 

그 직무집행에 있어서 헌법이나 법률을 위배한 때에는 국회는 탄핵의 소추를 의결할 수 있다.

② 1항의 탄핵소추는 국회재적의원 3분의 1 이상의 발의가 있어야 하며그 의결은 국회재적의원 과반수의 찬성이 있어야 한다다만대통령에 

대한 탄핵소추는 국회재적의원 과반수의 발의와 국회재적의원 3분의 2 이상의 찬성이 있어야 한다.

  ③ 탄핵소추의 의결을 받은 자는 탄핵심판이 있을 때까지 그 권한행사가 정지된다.

  ④ 탄핵결정은 공직으로부터 파면함에 그친다그러나이에 의하여 민사상이나 형사상의 책임이 면제되지는 아니한다.

 

111 ① 헌법재판소는 다음 사항을 관장한다.

  2. 탄핵의 심판

 

113 ① 헌법재판소에서 법률의 위헌결정탄핵의 결정정당해산의 결정 또는 헌법소원에 관한 인용결정을 할 때에는 재판관 6인 이상의 찬성이

있어야 한다.

 

□ 탄핵을 위한 국회 절차 : 국회법

 

37(상임위원회와 그 소관) ① 상임위원회와 그 소관은 다음과 같다.

  2. 법제사법위원회

    탄핵소추에 관한 사항

 

                            11장 탄핵소추

 

130(탄핵소추의 발의) ① 탄핵소추의 발의가 있은 때에는 의장은 발의된 후 처음 개의하는 본회의에 보고하고본회의는 의결로 법제사법위원회에

회부하여 조사하게 할 수 있다

② 본회의가 제1항에 의하여 법제사법위원회에 회부하기로 의결하지 아니한 때에는 본회의에 보고된 때로부터24시간이후 72시간 이내에 탄핵소추의

여부를 무기명투표로 표결한다이 기간 내에 표결하지 아니한 때에는 그 탄핵소추안은 폐기된 것으로 본다.

  ③ 탄핵소추의 발의에는 피소추자의 성명·직위와 탄핵소추의 사유·증거 기타 조사상 참고가 될 만한 자료를 제시하여야 한다.

 

131(회부된 탄핵소추사건의 조사) ① 법제사법위원회가 제130조의 발의를 회부 받았을 때에는 지체 없이 조사·보고하여야 한다.

  ② 1항의 조사에 있어서는 「국정감사 및 조사에 관한 법률」이 규정하는 조사의 방법 및 조사상의 주의의무규정을 준용한다.

 

132(조사의 협조조사를 받는 국가기관은 그 조사를 신속히 완료시키기 위하여 충분한 협조를 하여야 한다.

 

133(탄핵소추의 의결본회의의 탄핵소추의 의결은 피소추자의 성명·직위 및 탄핵소추의 사유를 표시한 문서(이하 "소추의결서"라 한다)로 하여야 한다.

 

134(소추의결서의 송달과 효과) ① 탄핵소추의 의결이 있은 때에는 의장은 지체 없이 소추의결서의 정본을 법제사법위원장인 소추위원에게그 등본을 

헌법재판소·피소추자와 그 소속기관의 장에게 송달한다.

  ② 소추의결서가 송달된 때에는 피소추자의 권한행사는 정지되며임명권자는 피소추자의 사직원을 접수하거나 해임할 수 없다.

 

□ 탄핵심판을 위한 헌법재판 절차 : 헌법재판소법

 

23(심판정족수) ① 재판부는 재판관 7명이상의 출석으로 사건을 심리한다.

② 재판부는 종국심리(終局審理)에 관여한 재판관 과반수의 찬성으로 사건에 관한 결정을 한다다만다음 각 호의 어느 하나에 해당하는 경우에는 재판관 

6명 이상의 찬성이 있어야 한다.

  1. 법률의 위헌결정탄핵의 결정정당해산의 결정 또는 헌법소원에 관한 인용결정(認容決定)을 하는 경우

 

26(심판청구의 방식) ① 헌법재판소에의 심판청구는 심판절차별로 정하여진 청구서를 헌법재판소에 제출함으로써 한다다만위헌법률심판에서는 법원의 

제청서탄핵심판에서는 국회의 소추의결서(訴追議決書)의 정본(正本)으로 청구서를 갈음한다.

  ② 청구서에는 필요한 증거서류 또는 참고자료를 첨부할 수 있다.

 

30(심리의 방식) ① 탄핵의 심판정당해산의 심판 및 권한쟁의의 심판은 구두변론에 의한다.

 

4장 제2절 탄핵심판 

 

48(탄핵소추다음 각 호의 어느 하나에 해당하는 공무원이 그 직무집행에서 헌법이나 법률을 위반한 경우에는 국회는 헌법 및 「국회법」에 따라 탄핵의

소추를 의결할 수 있다.

  1. 대통령국무총리국무위원 및 행정각부(行政各部)의 장

 

49(소추위원) ① 탄핵심판에서는 국회 법제사법위원회의 위원장이 소추위원이 된다.

  ② 소추위원은 헌법재판소에 소추의결서의 정본을 제출하여 탄핵심판을 청구하며심판의 변론에서 피청구인을 신문할 수 있다.

 

50(권한 행사의 정지탄핵소추의 의결을 받은 사람은 헌법재판소의 심판이 있을 때까지 그 권한 행사가 정지된다.

 

51(심판절차의 정지피청구인에 대한 탄핵심판 청구와 동일한 사유로 형사소송이 진행되고 있는 경우에는 재판부는 심판절차를 정지할 수 있다.

 

52(당사자의 불출석) ① 당사자가 변론기일에 출석하지 아니하면 다시 기일을 정하여야 한다.

  ② 다시 정한 기일에도 당사자가 출석하지 아니하면 그의 출석 없이 심리할 수 있다.

 

53(결정의 내용) ① 탄핵심판 청구가 이유 있는 경우에는 헌법재판소는 피청구인을 해당 공직에서 파면하는 결정을 선고한다.

  ② 피청구인이 결정 선고 전에 해당 공직에서 파면되었을 때에는 헌법재판소는 심판청구를 기각하여야 한다.

 

54(결정의 효력) ① 탄핵결정은 피청구인의 민사상 또는 형사상의 책임을 면제하지 아니한다.

  ② 탄핵결정에 의하여 파면된 사람은 결정 선고가 있은 날부터 5년이 지나지 아니하면 공무원이 될 수 없다.     

<이상입니다.>

 

2016년 11월 22일 화요일

MySQL의 삭제된 레코드 복구 실습


[Tech Report MySQL Forensics] 저장방식에 대한 ‘이해’가 데이터 복구의 ‘시작’이다



  • AhnLab


  • 2014-03-03

지난 2013년 12월호부터 월간 안을 통해 세 차례에 걸쳐 InnoDB와 MyISAM의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안에 대해 알아보았다. 이번에는 예제를 통해 삭제된 데이터에 대한 접근과 삭제된 데이터를 복구해가는 실제 과정을 살펴볼 예정이다. 이에 앞서 InnoDB와 MyISAM의 구조와 관련해 중요한 부분을 다시 한 번 살펴보고 각 저장방식의 구조적인 특징을 바탕으로 삭제된 레코드를 실제로 복구하는 과정을 알아본다. 테스트 환경을 구성하여 삭제된 레코드에 대해 실제로 복구 과정을 수행함으로써 MySQL이 DB 파일에 데이터를 어떻게 저장하고 사용하는지 데이터 저장의 흐름을 파악할 수 있기 때문에 분석가에게는 꼭 필요한 과정이라 할 수 있다.

 

<연재 목차>

1부_MySQL의 현황 및 포렌식적 의미(2013년 12월 호)

2부_MySQL InnoDB Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안(2014년 1월 호)

3부_MySQL MyISAM Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안(2014년 2월 호)

4부_MySQL의 삭제된 레코드 복구 실습(이번 호)

 

MySQL을 사용하는 대부분의 시스템은 InnoDB 또는 MyISAM 저장방식을 사용하여 데이터를 저장한다. 각각의 저장방식은 구조적으로 많은 차이가 있으나 데이터를 저장하는 전체적인 흐름은 비슷하다. 따라서 InnoDB 또는 MyISAM 저장방식 중 한가지 저장방식만 이해하고 있으면 대부분의 MySQL 저장방식의 메커니즘을 파악할 수 있다. 저장방식에 대한 메커니즘과 데이터 저장의 흐름에 대한 이해가 있어야만 DB로부터 데이터를 추출할 때 실제 데이터가 저장된 위치에 쉽게 접근할 수 있다. 특히 삭제된 레코드의 복구는 실제 데이터가 존재하는 위치로의 접근을 통해 이루어지기 때문에 저장방식에 대한 메커니즘 파악은 중요한 의미를 갖는다. 이미 월간 안을 통해 여러 차례 디지털 포렌식의 관점에서 삭제된 레코드 복구의 중요성에 대해 충분히 설명했기 때문에 이 글에서는 다시 부연하지 않기로 하겠다.

 

InnoDB의 구조적 특징 및 복구



InnoDB는 MySQL 설치 시 설정된 데이터 저장경로에 ibdata 파일을 생성하여 데이터를 저장하고 관리한다. ibdata 파일은 크게 시스템 테이블 영역과 트랜잭션 영역, 데이터 영역으로 나뉘며 각각의 영역은 16,384 바이트 크기의 블록 단위로 구성되어 있다. 시스템 테이블 영역은 데이터베이스 관련 정보와 테이블 스키마 등의 정보를 갖게 되고 데이터 영역은 데이터가 실제로 저장되는 영역이다. ibdata 파일 내의 모든 블록은 파일 헤더(FilHeader)와 페이지 헤더(PageHeader), 그리고 각 블록이 포함하고 있는 레코드(Record)와 레코드 속성 헤더를 포함한 형태로 구성되어 있다.

 

 

[표 1] 파일 헤더(FilHeader)의 주요 항목(출처: MySQL, http://dev.mysql.com/doc/internals/)

 

 

 

[표 2] 페이지 헤더(PageHeader)의 주요 항목(출처: MySQL, http://dev.mysql.com/doc/internals/)

 

 

 

[표 3] 리던던트 포맷(Redundant Format)의 주요 속성 정보

(출처: MySQL, http://dev.mysql.com/doc/internals/)

 

 

[표 1]과 [표 2]는 주요 파일 헤더와 페이지 헤더로, 삭제된 레코드를 복구하는데 꼭 필요한 항목이다. [표 3]은 각 블록마다 여러 개로 존재할 수 있는 레코드들에 대한 헤더 값으로, 각 레코드들을 연결하는 역할을 한다. 

 




[그림 1] 시스템 테이블 영역의 블록 일부

 

 

[그림 1]은 시스템 테이블에 저장된 블록의 일부다. [그림 1]을 통해 이 블록은 FIL_PAGE_SPACE 값을 통하여 0x3AEEF9EE 값의 ID를 가지고 있음을 확인할 수 있다. FIL_PAGE_PREV와 FIL_PAGE_NEXT는 이 블록과 연결되어 있는 블록이 있는지를 나타내며, 0xFFFFFFFF 값을 갖고 있을 경우에는 연결되는 페이지가 없음을 의미한다. 따라서 [그림 1]의 블록은 현재 앞뒤로 연결되어 있는 블록이 없다.




블록과 블록이 연결되는 이유는 하나의 블록에 많은 데이터가 저장되어 더 이상 저장할 공간이 없는 경우 새로운 블록을 연결함으로써 데이터를 이어서 저장하기 위함이다. 이때 기존 블록은 FIL_PAGE_NEXT에 새로운 블록의 블록 번호를 입력하고, 새로운 블록은 FIL_PAGE_PREV에 기존 블록의 번호를 입력하여 저장한다.




각 블록은 FIL_PAGE_OFFSET에 현재 블록이 0번째부터 몇 번째에 위치하는지에 대한 고유한 값을 갖고 있으며 FIL_PAGE_PREV와 FIL_PAGE_NEXT는 연결된 블록 번호를 저장한다. FIL_PAGE_TYPE은 현재 블록의 타입을 정의하며, 0x45BF를 갖고 있으면 실제 데이터를 가지고 있는 Leaf 노드에 해당한다. 삭제된 데이터를 복구할 때는 바로 이 0x45BF를 갖고 있는 블록이 필요하다.




PAGE_FREE는 현재 블록에서 첫 번째로 삭제된 레코드의 위치를 나타낸다. [그림 1]의 PAGE_FREE는 0x0000 이므로 현재 삭제된 레코드가 없음을 알 수 있다.

 




[그림 2] 레코드와 레코드의 연결

 

 

[그림 2]와 같이 파일 헤더와 페이지 헤더가 모두 나타나면 innoDB의 특징인 스타트 마커(Start Maker) “인피멈(infimum)”이 나타난다. 인피멈은 그 자체로 레코드이면서 모든 블록의 첫 번째 레코드가 된다. 즉, 인피멈 또한 레코드이기 때문에 앞의 6 바이트는 리던던트(Redundant) 방식의 레코드 헤더가 된다. 참고로, MySQL의 버전과 상관없이 시스템 테이블의 모든 레코드는 리던던트 방식을 취한다. [그림 2]에 나타난 바와 같이 이 파일의 인피멈 레코드 헤더는 0x01 00 00 03 00 8D 이다.




첫 번째 숫자인 0을 2진수로 표현하면 0000이며, 이 중 3번째 0은 현재 레코드의 삭제 여부를 나타낸다([표 3] 참조). 0은 정상 레코드임을 나타내기 때문에 현재 레코드는 정상 레코드이다. 레코드 헤더의 마지막 2 바이트에 해당하는 0x00 8D는 다음에 연결된 레코드의 오프셋을 나타낸다. 따라서 0x00 8D위치로 이동하면 “SYS_FOREIGN”이라는 다음 레코드를 만날 수 있다.



이와 같이 모든 레코드는 레코드 헤더의 속성을 통해 모두 연결되어 있으며, 계속해서 연결을 찾아가면 블록에 존재하는 모든 레코드에 접근할 수 있다. 단, 정상 레코드들은 모두 정상 레코드와 연결되며 삭제된 레코드들은 오직 삭제된 레코드와 연결된다. 모든 연결이 끝나면 정상 레코드는 “서프리멈(supremum)”이라는 엔드 마커(End Maker)로 이동하게 된 후 레코드 탐색을 종료한다.

 

[표 4] 콤팩트 포맷의 주요 속성 정보(출처: MySQL, http://dev.mysql.com/doc/internals/)

 

월간 안 지난 호에서 설명한 바와 같이 MySQL 버전 5.0 이상부터는 데이터 영역의 레코드 헤더가 콤팩트 포맷으로 나타난다. 리던던트 포맷과는 다소의 차이가 있기 때문에 삭제된 레코드의 복구 시 이점을 유의할 필요가 있다.



 


결국 삭제된 레코드를 복구하기 위해서는 PAGE_FREE를 이용하여 제일 처음에 삭제된 레코드의 위치에 접근한 후 리던던트 포맷 또는 콤팩트 포맷의 속성 정보를 통해 다음에 삭제된 레코드를 계속 찾아내야 한다.

 

 

MyISAM의 구조적 특징 및 복구

 


MyISAM은 테이블의 구조 정보와 인덱스 정보, 테이블 내부에 저장될 데이터를 각각 정해진 파일에 분할하여 저장한다. 사용자 또는 시스템이 데이터베이스를 생성하는 경우, 설정된 저장경로에 데이터 베이스명의 디렉토리를 생성하며 테이블을 생성하면 테이블명의 MYD 파일과 MYI, FRM 파일을 동시 생성하여 데이터를 저장 및 관리한다. (월간 안 2월 호)



MYD 파일은 크게 Fixed 포맷과 Dynamic 포맷 두 가지로 구분되어 저장된다. 저장할 테이블이 가변길이를 위한 데이터 타입을 포함하는 경우 Dynamic 포맷으로 저장되고, 저장할 테이블이 고정길이 데이터 타입만을 포함하는 경우 Fixed 포맷으로 저장된다.

 


[표 5] 저장 방식에 따른 데이터 타입

 

이와 같이 테이블이 포함하는 데이터의 타입에 따라 포맷이 구분되기 때문에 테이블 정보를 포함하고 있는 FRM 파일의 분석을 통해 복구하고자 하는 테이블의 포맷을 확인해야 한다. 테이블의 포맷을 확인해 각 포맷의 특징에 맞게 복구를 진행해야 하기 때문이다. 레코드는 모두 MYD 파일에 저장되기 때문에 이 글에서는 MYD 파일에서의 복구를 예제로 실습을 진행해본다.

 

1. Fixed 포맷

 




[그림 3] Fixed 포맷의 MYD 파일

 

 

[그림 3]은 Fixed 포맷의 MYD 파일로, Fixed 포맷이기 때문에 하나의 레코드가 동일한 길이로 반복되고 있음을 알 수 있다. [그림 3]의 표시된 부분과 같이 레코드 헤더는 하나의 레코드가 시작되기 전 1바이트의 크기로 반복되어 나타난다. 레코드 헤더를 통해 현재 레코드의 상태를 확인할 수 있다.



[그림 3]의 첫 번째 레코드 헤더 값은 0xF1이며, 0xF1의 2진수 값(1111 0001) 중 마지막 비트인 1이 현재 레코드의 상태를 나타낸다. MyISAM은 innoDB와는 달리 마지막 비트가 1인 경우 현재 레코드가 정상 상태임을 의미하고 반대로 0인 경우에는 삭제된 레코드임을 의미한다.

 




[그림 4] 삭제된 레코드의 데이터 손실

 

[그림 4]의 경우, 두 번째 레코드 헤더 값 0x00을 통해 해당 레코드가 삭제되어 있음을 알 수 있다. MyISAM 저장방식은 레코드가 삭제된 경우 레코드 헤더 값 이후에 다음으로 삭제된 레코드의 오프셋 위치를 추가로 저장한다. 기존에 저장되어 있던 원본 데이터가 다음 삭제된 레코드와 관련된 데이터로 덮어 쓰여짐에 따라 일부 데이터의 손실이 발생한다. 또한 레코드를 삭제한 후 새로운 레코드가 추가 되었을 경우 삭제된 레코드 영역에 새로운 레코드가 덮어 쓰여지기 때문에 손상되었던 데이터 외에 일부 데이터도 복구할 수 없는 경우가 발생할 수 있다. MyISAM 저장방식의 경우 완전한 복구는 사실상 불가능하다는 점을 인지하고 있어야 한다.

 

 



[표 6] Fixed 포맷의 헤더 구조

 

MyISAM 저장 방식 Fixed 포맷의 헤더는 [표 6]과 같이 테이블이 갖고 있는 필드의 개수에 따라 헤더의 길이가 변경될 수 있다. 따라서 해당 테이블에 대한 정보를 명확하게 파악한 뒤 복구를 시작해야 한다.

 

2. Dynamic 포맷

 

[그림 5] Dynamic 포맷의 MYD 파일

 

[표 7] Dynamic 포맷의 헤더 구조

 

[그림 5]는 Dynamic 포맷으로 저장된 MYD 파일로, 총 4개의 레코드가 저장되어 있음을 알 수 있다. 각각의 레코드는 6 바이트의 헤더 값을 갖고 있다. 헤더 값에 대한 정의는 [표 7]을 참고하여 파악할 수 있다. Fixed 포맷과 마찬가지로 Dynamic 포맷 역시 테이블이 포함하는 필드의 개수 및 데이터의 길이에 따라 헤더 값의 길이가 변할 수 있다. 따라서 데이터 복구 시 테이블 정보를 잘 파악하여 이용해야 한다.



[그림 5]의 경우, 두 번째 레코드가 삭제된 레코드임을 알 수 있다. 레코드가 삭제되었을 경우에는 처음 4바이트에는 삭제된 레코드의 크기 값이 저장되어 있다. 또한 다음 8바이트에는 이전에 삭제된 레코드의 오프셋이 나오고 그 다음 8바이트에는 다음에 삭제된 레코드의 오프셋이 나온다. Dynamic 포맷도 Fixed 포맷과 마찬가지로 레코드가 삭제되면 20바이트 정도의 크기를 다른 값으로 덮어 쓰기 때문에 완전한 복구는 불가능하다.

 

실습을 통해 데이터 복구 방법론을 확보할 수 있어



월간 안 연재를 통해 MySQL의 이론적인 내용을 살펴본 것에 이어 이번에는 삭제된 데이터를 실제로 어떻게 복구할 수 있는지에 대한 방법에 대해 알아보았다. 대부분의 데이터베이스는 MySQL과 비슷한 방식의 메커니즘을 통하여 데이터를 저장하고 관리하기 때문에 실습을 통해 복구 과정을 숙지하면 다른 데이터베이스의 경우에도 구조의 파악만으로도 쉽게 데이터 복구를 위한 방법론을 완성할 수 있다. 이러한 복구 방안을 자동화하여 보다 빠르고 정확한 복구를 가능하게 한다면 수많은 다양한 데이터베이스들의 삭제된 레코드의 복구가 가능할 것이다. 특히 디지털 포렌식 관점에서는 다양한 데이터베이스의 복구 연구와 함께 데이터베이스의 삭제된 레코드를 통합적으로 복구할 수 있는 방안에 대해서 끊임없이 연구할 필요가 있겠다.@










  • AhnLab 로고



  • 클라우드분석팀 남궁재웅 연구원




이 정보에 대한 저작권은 AhnLab에 있으며 무단 사용 및 도용을 금합니다.

단, 개인이 비상업적인 목적으로 일부 내용을 사용하는 것은 허용하고 있으나, 이 경우 반드시 출처가 AhnLab임을 밝혀야 합니다.

기업이 이 정보를 사용할 때에는 반드시 AhnLab 의 허가를 받아야 하며, 허가 없이 정보를 이용할 경우 저작권 침해로 간주되어 법적인 제재를 받을 수 있습니다. 자세한 내용은 컨텐츠 이용약관을 참고하시기 바랍니다.

정보 이용 문의 : contents@ahnlab.com


MySQL MyISAM Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안


[Tech Report] MySQL MyISAM Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안



  • AhnLab


  • 2014-01-29

손상된 데이터에도 '의미'는 있다

 

MyISAM은 InnoDB와 더불어 MySQL의 대표적인 저장방식 중 하나이다. 모든 테이블과 데이터를 하나의 파일로 통합하여 관리하는 InnoDB와는 달리 MyISAM은 테이블별로 파일을 생성하여 해당 테이블과 관련된 모든 데이터를 각각의 테이블별 파일에 저장한다. 이처럼 테이블과 파일이 1:1 대응의 형태를 갖는 MyISAM은 데이터 관리가 매우 우수하며 데이터 처리 속도도 빠르다. 그러나 데이터 삭제 시, 관리 성능 및 빠른 처리 속도를 유지하기 위해 데이터가 존재했던 영역 일부에 삭제를 표시하기 위한 다른 값을 덮어쓴다. 결국 MyISAM은 완벽한 절차를 수행하더라도 삭제된 데이터를 온전히, 또는 모두 복구하기가 어렵다.



디지털 포렌식 관점에서는 비록 일부만 복구된 데이터라 할지라도 상당한 의미가 될 수 있기 때문에 이에 대한 복구 방안 마련이 필요하다. 이와 관련해 이번 호에서는 MyISAM 저장방식에서의 데이터 접근 방법을 살펴보고 삭제된 데이터의 복구 방안에 대해 알아본다.

 

 

<연재 목차>

1부_MySQL의 현황 및 포렌식적 의미(2013년 12월 호)

2부_MySQL InnoDB Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안(2014년 1월 호)

3부_MySQL MyISAM Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안(이번 호)

 

 

지난 월간 안 1월호에서 살펴보았던 InnoDB 저장방식에 비해 MyISAM 저장방식은 빠른 속도로 대용량의 데이터를 처리할 수 있는 장점을 갖고 있다. MyISAM은 MySQL의 초기 버전부터 메인 저장방식으로 사용되었으며, MySQL 5.5 버전 출시 이후 InnoDB 저장방식으로 변경되기 전까지 MySQL의 기본 저장방식으로 사용되었다.



MyISAM은 트랜잭션 기능을 지원하지 않으며 외래 키(Foreign Key)를 지원하지 않기 때문에 시스템이 손상되었을 경우 데이터의 복구가 어렵고 데이터의 품질을 향상시키기 어렵다는 단점이 있다. 그러나 이 같은 단점에도 불구하고 대다수의 MySQL 사용자는 MyISAM의 빠른 속도와 사용상의 편의성 때문에 여전히 이를 기본 저장방식으로 사용하고 있다. 이 같은 MyISAM의 높은 사용률때문에라도 이에 대한 분석 및 복구 방안 연구는 디지털 포렌식 관점에서 상당히 중요한 의미를 갖는다.

 

 

MyISAM의 구조적 특징



MyISAM은 테이블의 구조 정보와 인덱스 정보, 테이블 내부에 저장될 데이터 등을 각각의 정해진 파일에 분할하여 저장한다. 각각의 파일은 저장된 정보를 통하여 데이터 관리의 효율을 높이기 위한 역할을 수행한다. 일반적으로 MySQL은 [그림 1]과 같이 사용자 또는 시스템이 데이터베이스를 생성하는 경우 기 설정된 저장경로에 데이터베이스명의 디렉터리를 생성한다.

 

ㅇㄴㄹㄴㅇㄹ

 

 

이후 생성한 데이터베이스 내부에서 [그림 2]와 같은 쿼리를 이용해 MyISAM 저장방식의 테이블을 생성하면 데이터베이스명의 디렉터리 내부에 테이블명의 MYD 파일과 MYI, FRM 파일을 동시에 생성된다([그림 3]).

 

ㄴㅇㄹㅇㄴㄹ

 

 

ㄴㅇㄹㄴ 

 

 

일반적으로 대부분의 DB는 [그림 4]와 같은 구조로 이루어져 있다. 따라서 원하는 위치의 데이터에 접근하기 위해서는 원하는 데이터베이스와 테이블을 알아야 한다. 특히 MySQL에서는 접근하고자 하는 테이블이 MyISAM 또는 InnoDB 중 어느 것인지를 구분하는 절차가 필요하다.

 

ㄴㅇㄹ

 

  

MyISAM 구성 파일

 

앞서 설명한 바와 같이 MySQL은 사용자 또는 시스템이 데이터베이스를 생성할 때 지정된 저장경로에 데이터베이스명의 디렉터리를 생성한다. 또한 MySQL의 MyISAM 저장방식은 데이터베이스 내부에 테이블을 생성하는 경우, 데이터베이스명의 디렉터리 안에 테이블 정보와 인덱스 정보, 테이블에 저장될 데이터를 각각 테이블명의 파일로 저장한다. 일반적으로 테이블의 구조 정보는 FRM 파일에 저장되고 인덱스 정보는 MYI 파일에 저장되며 실제 데이터에 해당하는 레코드들은 MYD 파일에 저장된다. 포렌식을 위해 삭제된 데이터를 복구하는 경우에는 테이블의 구조를 저장하고 있는 FRM 파일과 데이터를 저장하고 있는 MYD 파일을 반드시 수집해야 한다. 물론 MYI 파일까지 모두 수집할 수 있다면 보다 효과적인 복구가 가능하다. 따라서 삭제된 데이터를 복구할 경우, FRM 파일과 MYD 파일을 손상 없이 수집할 수 있는 여러 가지 방안 및 대안이 필요하다.

 

ㅇㄹㄴㅇ

 

1. MYD 파일

 

MySQL의 MyISAM 저장방식은 FRM 파일에 저장된 테이블 스키마 정보를 참조하여 데이터를 레코드 단위로 MYD 파일에 저장한다. MYD 파일의 저장방식은 해당 테이블의 필드가 가변 길이의 데이터 타입을 포함하고 있는지의 여부에 따라 Fixed 포맷과 Dynamic 포맷, 두 가지로 구분된다. MySQL은 가변길이를 위한 데이터 타입으로 VARCHAR, TEXT, BLOB 등의 타입을 제공하고 있으며 테이블이 해당 데이터 타입을 포함하는 경우 Dynamic 포맷으로 분류된다.

 

 

 MYD 파일에 저장되는 레코드는 Fixed 포맷 또는 Dynamic 포맷의 여부에 따라 저장방식에 큰 차이가 있으며 헤더 값 또한 다르다. 따라서 완성도 있는 복구를 위해서는 Fixed 포맷과 Dynamic 포맷에 대한 철저한 분석이 필요하다.

 

1) Fixed 포맷

 

MYD 파일은 테이블이 가변 길이 데이터 타입을 포함하지 않을 경우 데이터를 Fixed 포맷으로 저장한다.

 

 

 

[그림 5]는 Fixed 포맷으로 저장된 MYD 파일로, Fixed 포맷의 MYD 파일은 레코드 단위의 데이터를 순차적으로 저장한다. 또한 데이터 저장 시, 하나의 레코드당 하나의 헤더 값을 부여한다. 헤더 값은 레코드의 속성을 표현하며, 테이블 내부의 필드 개수가 많지 않은 경우 일반적으로 총 1 바이트의 길이다. 필드의 개수가 많아지는 경우 헤더의 길이도 늘어난다.

 

 

헤더 값은 비트 단위로 해당 레코드의 속성을 나타내며, 해당 레코드의 최하위 비트가 1이면 정상 레코드이다. 헤더 값의 최하위 비트가 0인 경우, 해당 레코드는 삭제된 레코드이다. [그림 5]의 경우, 현재 총 3개의 레코드가 해당 테이블에 저장되어 있음을 알 수 있으며 색깔에 따라 레코드가 구분되어 있음을 확인할 수 있다. 첫 번째 레코드와 세 번째 레코드의 헤더 값은 0xF1 (2진수 값: 1111 0001)을 나타내고 있으며 최하위 비트가 1 이기 때문에 정상적으로 저장되어 있는 레코드 임을 알 수 있다.

 

두 번째 레코드는 0x00(2진수 값: 0000 0000)의 헤더 값을 가지고 있으며 최하위 비트가 0 이므로 삭제된 레코드 임을 알 수 있다. 또한 레코드 앞부분의 일정 부분은 0xFF 값의 일부가 덮어 쓰여져 있으므로 원본 데이터가 영구 삭제되었음을 알 수 있다.

 

 

[표 3]은 Fixed 포맷의 헤더 구조를 나타내는 것이다. 레코드 헤더를 통해 해당 레코드의 삭제 여부를 판단할 수 있다. 삭제된 레코드를 복구하기 위해서는 각 레코드의 헤더 값에 어떠한 속성이 부여 되었는지를 파악할 수 있어야 한다.

 

2) Dynamic 포맷

MYD 파일은 테이블이 가변 길이 데이터 타입(BLOB, VARCHAR, TEXT 등)을 포함하는 경우, Dynamic 포맷으로 데이터를 저장한다.

 

 

 

[그림 7]은 Dynamic 포맷으로 저장된 MYD 파일이다. Dynamic 포맷의 MYD 파일은 Fixed 포맷과 마찬가지로 데이터를 레코드 단위로 순차적으로 저장하며 하나의 레코드 당 하나의 헤더 값을 포함한다. 그러나 Dynamic 포맷은 Fixed 포맷과는 달리 가변된 길이에 대한 정보를 헤더에 따로 포함하고 있고 데이터의 얼라이먼트(alignment)를 유지하기 위해 패딩(padding)된 길이 정보도 포함한다. 또한 Dynamic 포맷은 하나의 레코드 길이가 가변 길이와 상관없이 최소 20 바이트를 유지하고 있다. 하나의 레코드 길이가 20 바이트를 채우지 못하는 경우에는 나머지 공간을 Null 값으로 채운다.

 

 

 

 

Fixed 포맷의 파일은 최상위 비트 하나만으로 레코드의 삭제 여부를 판단할 수 있었던 것과 달리 Dynamic 포맷의 파일은 헤더의 첫 번째 바이트에 레코드의 속성을 부여한다. 일반적으로 헤더의 첫 번째 바이트의 값이 0x00 인 경우 해당 레코드는 삭제된 레코드로 표현된다. 헤더의 첫 번째 바이트 값이 0x00 보다 큰 경우에는 정상 레코드로 분류된다. 따라서 Dynamic 포맷의 파일의 삭제된 레코드를 복구하기 위해서는 첫 번째 바이트의 속성 값을 파악하는 것이 중요하다.

 

2. FRM 파일

사용자나 시스템에 의해 생성된 테이블 스키마 정보는 테이블명으로 생성된 FRM 파일에 저장된다. MySQL은 FRM 파일의 테이블 스키마를 통해 데이터를 저장 및 관리할 수 있는 정보를 제공한다.

 

 



 

[그림 8]은 FRM 파일을 통하여 테이블이 어떠한 형태로 구성되어 있는지를 보여준다. FRM 파일을 통하여 해당 테이블의 필드명과 데이터 타입, 할당된 길이 정보 등을 파악할 수 있다. 데이터 타입은 숫자형, 문자형, 날짜형 등 다양한 타입이 존재한다.

 

MYD 파일은 문자형의 가변 길이 데이터 타입이 테이블에 포함되는 경우 Dynamic 포맷으로 데이터를 저장한다. FRM 파일은 InnoDB와 동일한 형태로 테이블 스키마가 저장된다. 즉, InnoDB 역시 MyISAM와 마찬가지로 FRM 파일을 통해 테이블의 정보를 확인한다. 따라서 완성도 높은 레코드 복구를 위해서는 FRM 파일을 통해 필드명과 데이터 타입 등을 확인해야 한다.

 

 

 

MyISAM의 삭제된 레코드 복구

 

MyISAM 저장방식은 레코드가 삭제되는 경우 포맷에 따라 헤더 값의 표기가 다르다. Fixed 포맷은 해당 레코드 헤더의 최하위 비트를 0으로 표기하며, Dynamic 포맷은 헤더의 첫 번째 바이트의 값을 0x00으로 표기한다. 따라서 삭제된 레코드를 복구하는 방법도 포맷에 따라 각기 다르다.

 

Fixed 포맷의 경우, FRM 파일에 저장된 테이블 스키마를 통해 하나의 레코드가 차지하는 길이를 계산하여 레코드 단위로 MYD 파일 내부의 모든 레코드들을 순차적으로 읽으면서 삭제 여부를 파악한다. 삭제된 레코드는 테이블 구조에 맞게 각 필드의 데이터 값을 잘라서 복구한다. Dynamic 포맷의 경우에는 각 레코드마다 가변 길이로 저장된 필드의 길이와 고정 길이로 저장된 필드의 길이를 더하여 하나의 레코드가 차지하는 길이를 계산한다. 그후 Fixed 포맷과 같은 방식으로 순차적으로 읽으면서 복구를 진행할 수 있다.

 

결국 테이블의 구조를 얼만큼 정확하게 파악하느냐에 따라 데이터를 구분이 수월하며, 각 레코드의 헤더 값을 얼마나 정확하게 파악하느냐에 따라 복구할 수 있는 데이터의 양이 많아진다. 그러나 MyISAM 저장방식은 레코드를 삭제한 후 새로운 레코드를 저장하면 이 새로운 레코드가 삭제된 레코드가 존재하는 위치를 덮어쓰게 된다. 데이터 저장의 공간적인 측면에서는 덮어쓰는 방식이 유용하지만 삭제된 레코드의 복구 관점에서는 기존의 삭제된 데이터가 다른 데이터로 덮어 쓰여지면 해당 영역에 대한 데이터 복구는 불가능하다. 데이터베이스에서 레코드의 생성 및 삭제는 빈번히 발생하기 때문에 레코드의 삭제 시점이 오래될수록 레코드의 복구 확률은 낮아진다고 볼 수 있다. 또한 앞서 살펴본 바와 같이 MyISAM 저장방식에서는 레코드 삭제 시 Fixed 포맷은 4 바이트, Dynamic 포맷은 20 바이트 길이만큼 삭제 관련 정보로 덮어쓴다. 따라서 MyISAM 저장방식에서는 데이터를 복구하더라도 일부 데이터의 손상을 막을 수는 없다.



지금까지 3회에 걸쳐 MySQL에서의 삭제된 레코드에 대한 복구 방안에 대하여 알아보았다. 복구 방법을 파악했으니 이제 실제로 복구하는 과정을 살펴볼 차례다. 다음 '월간 안'을 통해 간단한 테스트 데이터와 함께 삭제된 레코드의 실제 복구 과정에 대하여 소개할 예정이다.@










  • AhnLab 로고



  • 클라우드분석팀 남궁재웅 연구원




이 정보에 대한 저작권은 AhnLab에 있으며 무단 사용 및 도용을 금합니다.

단, 개인이 비상업적인 목적으로 일부 내용을 사용하는 것은 허용하고 있으나, 이 경우 반드시 출처가 AhnLab임을 밝혀야 합니다.

기업이 이 정보를 사용할 때에는 반드시 AhnLab 의 허가를 받아야 하며, 허가 없이 정보를 이용할 경우 저작권 침해로 간주되어 법적인 제재를 받을 수 있습니다. 자세한 내용은 컨텐츠 이용약관을 참고하시기 바랍니다.

정보 이용 문의 : contents@ahnlab.com


MySQL InnoDB Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안


[Tech Report] MySQL Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안



  • AhnLab


  • 2014-01-06

구조를 알면 데이터가 보인다

 

오픈소스 라이선스 기반의 DB 관리 시스템인 MySQL은 일반적으로 InnoDB 또는 MyISAM이라는 두 가지의 저장 방식(Storage Engine) 중 하나의 방식을 사용하여 데이터를 저장한다. InnoDB와 MyISAM은 각각의 절차와 구조에 따라 데이터를 읽거나 저장한다. 따라서 이들 저장 방식의 구조를 이해하면 데이터에 직접 접근할 수 있을 뿐만 아니라 DB 내부의 완전히 삭제되지 않은 데이터에 대한 접근 및 복구도 가능하다. 포렌식에서 삭제된 데이터의 복구는 공격자의 고의적인 데이터 은닉이나 삭제를 밝혀낸다는 점에서 중요한 의미를 갖는다. 이 글에서는 MySQL의 저장 방식 중 InnoDB 저장 방식의 구조를 분석하여 직접적으로 데이터에 접근하는 방법을 살펴보고 삭제된 데이터의 복구 방안에 대해 알아본다. MyISAM 저장 방식에 대해서는 3부에서 살펴볼 예정이다.

 

<연재 목차>


1부_MySQL의 현황 및 포렌식적 의미(2013년 12월 호)

2부_MySQL InnoDB Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안(이번 호)
3부_ MySQL MyISAM Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안

 

 

InnoDB는 대용량 데이터를 처리하기 위해 설계된 저장 방식이다. 기존의 저장 방식과는 달리 트랜잭션 기능을 포함하여 안전성을 크게 강화하였으며 외래 키(Foreign Key) 지원을 통한 무결성의 보장으로 데이터의 품질을 향상시키는 데 기여한다. 이 같은 다양한 장점을 기반으로 MySQL은 5.5 버전부터 InnoDB 방식을 기본 저장 방식으로 설치하고 있다.

 

InnoDB의 구조적 특징



InnoDB는 페이지 단위의 각 데이터들의 집합체이다. MySQL 설치 시 설정된 데이터 저장경로에 ibdata 파일을 생성하여 관련 데이터를 저장한다. 하나의 페이지는 일반적으로 16,384바이트(16KB)의 크기로 이루어져 있으며 ibdata 내부에 여러 개의 페이지가 순차적으로 저장되어 하나의 파일을 이룬다(경우에 따라 ibdata 파일을 분할하여 다수의 파일로 저장하는 것도 가능하다).



[그림 1]은 ibdata 파일의 내부 구조를 나타낸 것이다. 일반적으로 시스템 테이블(System Table) 영역과 트랜잭션 (Transaction) 영역, 그리고 데이터(Data) 영역으로 나눌 수 있다.

 



시스템 테이블 영역은 DB의 시스템이 생성한 영역이다. 사용자가 생성한 데이터베이스와 테이블, 테이블에 대한 메타 정보 등을 정리하여 관리한다. 또한 시스템 테이블 영역을 통해 현재 어떤 데이터베이스와 테이블이 생성되어 있는지 파악할 수 있으며 테이블 내에 생성된 필드, 필드의 데이터 타입 등 다양한 정보 수집이 가능하다.




트랜잭션 영역은 DB가 쿼리를 처리하는 과정에서 시스템 상의 오류가 발생할 경우 원상태로 복구하기 위해 쿼리 처리 이전의 데이터를 보관하는 영역이다.



데이터 영역은 실제 데이터가 저장되는 영역으로, DB 사용자가 저장한 모든 데이터는 이 영역에 저장된다. 이 영역에서는 DB의 성능을 유지하기 위해 데이터 삭제 시, 완전 삭제 대신 데이터가 삭제된 것으로 표시만 하고 삭제 영역에 데이터를 그대로 유지한다. 이 같은 특징 때문에 삭제된 데이터의 복구가 가능하다.

 

InnoDB 구성 파일


앞서 설명한 바와 같이 InnoDB는 모든 데이터를 ibdata 파일에 페이지 단위로 기록한다. 디스크 기반 저장 방식인 MyISAM과는 달리 InnoDB는 각각의 데이터를 파일 단위로 따로 저장하지 않고 하나의 파일 안에 모두 저장한다. 따라서 데이터가 축적될수록 ibdata 파일의 용량도 증가한다. InnoDB는 데이터베이스를 생성할 때 기존에 설정된 데이터 저장 위치(ibdata 파일이 존재하는 위치)에 데이터베이스명의 폴더를 생성한다. 데이터베이스를 생성하고 테이블을 생성하는 경우에는 해당 데이터베이스명의 폴더에 생성한 테이블명으로 frm이라는 확장자의 파일을 생성한다.

 

 

frm 파일은 MyISAM 방식에서도 동일하게 사용하는 파일이다. frm 파일 내부에는 테이블에 대한 각종 정보와 테이블을 구성하는 각 필드의 필드명과 데이터 타입에 대한 정보가 존재한다. InnoDB 저장 방식으로 생성된 테이블은 frm 파일을 생성함과 동시에 동일한 내용을 ibdata에 저장하기 때문에 frm 파일이 존재하지 않아도 데이터를 복구할 수 있다. 따라서 frm의 구조에 대해서는 frm 파일이 필수적으로 필요한 MyISAM 방식과 함께 3부에서 살펴보도록 하겠다.

 

InnoDB 헤더 구조


ibdata 파일은 각각의 데이터를 쉽게 구분하기 하기 위해 데이터를 페이지(블록) 단위로 구성하고 있다. 하나의 페이지는 16,384 바이트며, 여러 개의 페이지를 하나로 합친 것이 ibdata 파일이다. ibdata는 각 페이지의 상단(헤더)에는 해당 페이지의 속성을 정의하는 다양한 정보가 존재하기 때문에 헤더가 갖고 있는 값에 주목할 필요가 있다.

 

 

일반적으로 리프 노드에 해당하는 모든 페이지들은 [그림 2]와 같이 파일 헤더(FilHeader)와 페이지 헤더(PageHeader), 레코드(Record) 속성, 데이터(Data) 항목으로 구성되어 있다. 각 페이지에는 페이지의 시작 위치를 기준으로 [표 2]의 파일 헤더 항목과 [표 3]의 페이지 헤더와 같은 다양한 속성 값이 순차적으로 위치한다.

 

 

 


 

 

[표 2]와 [표 3]은 [그림 2]가 어떤 헤더 값을 갖고 있는지 보여준다. InnoDB는 기본적으로 ibdata 파일의 리프 노드에 모든 데이터를 저장한다. 따라서 InnoDB 방식의 데이터베이스를 분석하기 위해서는 리프 노드에 초점을 맞추어 분석을 진행해야 한다. 리프 노드는 페이지의 FIL_PAGE_TYPE 값(0x45BF)을 확인하여 찾을 수 있다. FIL_PAGE_TYPE 값을 확인해 해당 페이지가 리프 노드로 판단되면 어떤 데이터가 입력되어 있는지 분석할 수 있다.



[표 4]는 FIL_PAGE_TYPE 항목에 올 수 있는 값을 설명한 것이다. 해당 표의 FIL_PAGE_INDEX (0x45BF) 값이 리프 노드에 해당되며, 데이터 복구를 위해 중요한 항목이다.

 


버전별 InnoDB 복구 방안



MySQL의 InnoDB 저장 방식은 하나의 레코드에 하나의 속성을 부여하여 헤더 위치에 저장한다([그림 2]). 레코드 속성은 크게 리던던트 포맷(redundant format)과 콤팩트 포맷(compact format)으로 구분된다. 리던던트 포맷은 InnoDB 저장 방식이 생긴 이후로 현재까지 사용되고 있는 포맷이다. 콤팩트 포맷은 MySQL 5.0 버전 이후 리던던트 포맷의 비효율성을 해결하고 데이터를 효율적으로 관리하기 위해 도입된 포맷이다. 리던던트 포맷과 콤팩트 포맷은 각각의 레코드가 저장되기 전에 6바이트 길이로 헤더에 저장된다. 각 포맷을 통해 정의된 헤더 값은 각 레코드의 속성 정보를 파악할 수 있게 해준다. 리던던트 포맷과 콤팩트 포맷의 각 항목은 비트 단위로 구성되어 있으며 각 항목의 비트 길이에 따라 계산하여 해당 항목의 값을 계산할 수 있다.



[표 5]는 리던던트 포맷의 각 항목과 비트 수 등을 설명한 것으로, 속성 정보를 통해 현재 레코드의 상태 정보와 삭제 여부, 최소 레코드의 속성, 소유하는 레코드의 개수, 다음 레코드의 오프셋 정보 등을 확인할 수 있다.

 



 

[그림 3]은 각 레코드의 앞 6바이트에 존재하는 리던던트 포맷의 헤더이다. 이와 같이 InnoDB에서 레코드 속성은 6바이트의 속성 정보를 통해 정의되며 속성 정보와 함께 각 필드의 길이 정보도 포함하고 있다. 이 같은 방법을 통해 MySQL 4 버전의 InnoDB 저장 방식의 데이터를 분석할 수 있다.




InnoDB 저장 방식은 MyISAM에 비해 삭제된 레코드의 분석시에도 장점이 있다. MyISAM이 필드의 일부를 다른 정보로 덮어쓰는 것과 달리 InnoDB는 레코드의 속성 정보에서 deleted_flag 값만 1로 바꾼 후 더 이상의 수정을 하지 않는다. 따라서 삭제된 지 오래된 레코드도 복구할 수 있는 가능성이 높다. 또한 MyISAM에 비해 데이터를 새로운 레코드가 덮어쓸 가능성이 낮기 때문에 복구시에도 상당히 유리하다.

 


MySQL 5 버전으로 넘어가면서 InnoDB는 기존에 사용하던 리던던트 포맷은 그대로 사용하면서 콤팩트 포맷을 추가로 도입하였다. 기존 4 버전의 데이터베이스 시스템 관련 필드와 유저 관련 필드가 모두 리던던트 포맷이었던 반면, 5 버전부터는 효율성을 위해 시스템 관련 필드는 리던던트 포맷을 사용하고 유저 관련 필드는 콤팩트 포맷을 사용하도록 개선되었다. 콤팩트 포맷은 기존의 리던던트 포맷과 같이 6바이트의 길이를 차지하고 있지만 실제로 활용하는 길이는 5바이트이다.

 

[표 6]은 유저 관련 필드의 레코드 속성을 정의하는 콤팩트 포맷이 나타내는 속성 정보이다. 콤팩트 포맷은 리던던트 포맷과 큰 차이는 없으며, 더 실용적인 데이터 활용을 위해 자주 사용되지 않는 두 개의 필드를 제거하였다. InnoDB는 각각의 레코드 속성을 통해 각 레코드의 상태를 파악할 수 있다. 이를 통해 정상적으로 존재하는 레코드인지, 삭제된 레코드인지 여부를 판단할 수 있다.




InnoDB는 페이지 헤더의 PAGE_HEAP_TOP 값을 이용해 정상 레코드의 시작 위치를 정의한다. 각 레코드는 리던던트 포맷 및 콤팩트 포맷의 속성 중 next 16bits를 통해 다음 정상 레코드의 위치로 연결된다. 마찬가지로 삭제된 레코드는 페이지 헤더의 PAGE_FREE 값을 통하여 첫 번째 삭제된 레코드의 위치로 연결되며 next 16bits를 통해 다음 삭제된 레코드의 위치로 연결된다. 따라서 페이지에서 첫 번째 정상 데이터, 또는 첫 번째 삭제된 데이터의 위치만 찾으면 링크를 통해 모든 정상 데이터와 삭제된 데이터를 찾을 수 있다. 링크를 통한 분석은 특정 레코드를 빠르게 분석하는 데 편리하다.

 

InnoDB, 복구의 안전성과 신뢰도 높아

디지털 포렌식 관점에서 삭제된 레코드의 복구는 공격자가 고의로 은닉하거나 삭제한 데이터를 복구할 수 있다는 점에서 중요한 의미를 갖는다. 따라서 가능한 많은 복구를 이뤄내는 것은 중요하다.




InnoDB의 ibdata 파일은 페이지 단위로 구분할 수 있으며 각 페이지의 속성 값을 통해 해당 페이지가 리프 노드인지 여부를 파악할 수 있다. 리프 노드에 일반적인 레코드 값이 저장되어 있기 때문에 리프 노드를 구분하는 것이 중요하다. 리프 노드의 페이지에서 페이지 헤더를 이용해 첫 번째 정상 레코드 또는 첫 번째 삭제 레코드를 확인할 수 있으며 하나의 레코드를 복구하면 대부분의 레코드 복구가 가능하기 때문이다.




InnoDB는 버전에 따라 각 레코드에 사용하는 포맷이 다르다. 따라서 각 버전에 따라 각기 다른 형태로 분석해야 한다. 또한 삭제된 레코드에 대한 데이터 손상이 크지 않기 때문에 복구 관점에서도 안전성과 신뢰도가 높다.



InnoDB는 frm 파일과 함께 분석이 이루어지면 테이블 단위의 추출이 가능하며 더욱 정교한 분석이 가능하다. 3부에서는 frm의 구조 분석과 함께 MyISAM이 어떻게 복구되는지 살펴보며 InnoDB와 어떻게 연결되어 데이터를 추출하고 복구할 수 있는지 알아보도록 하겠다.@










  • AhnLab 로고



  • 클라우드분석팀 남궁재웅 연구원




이 정보에 대한 저작권은 AhnLab에 있으며 무단 사용 및 도용을 금합니다.

단, 개인이 비상업적인 목적으로 일부 내용을 사용하는 것은 허용하고 있으나, 이 경우 반드시 출처가 AhnLab임을 밝혀야 합니다.

기업이 이 정보를 사용할 때에는 반드시 AhnLab 의 허가를 받아야 하며, 허가 없이 정보를 이용할 경우 저작권 침해로 간주되어 법적인 제재를 받을 수 있습니다. 자세한 내용은 컨텐츠 이용약관을 참고하시기 바랍니다.

정보 이용 문의 : contents@ahnlab.com


MySQL의 현황 및 포렌식적 의미


[Tech Report] 그들은 왜 아직도 MySQL을 사용하는가?



  • AhnLab


  • 2013-12-03

MySQL의 현황 및 포렌식적 의미

 


데이터베이스(Database, 이하 DB)는 방대한 양의 데이터에 빠르고 쉽게 접근하고 처리할 수 있도록 구성된 데이터의 집합체이다. 데이터의 홍수 속에서 대부분의 기업은 물론 일반 사용자들도 크고 작은 다양한 DB를 이용하여 데이터를 관리 및 저장한다. 일반적으로 각각의 DB는 고유의 데이터 관리 체계를 갖고 있으며, 이를 통해 데이터를 파일에 담아 저장 및 관리한다. 이 같은 DB의 데이터 관리 체계를 분석하여 DB 내에 저장된 데이터에 직접적으로 접근할 수 있으며 다양한 분석이 가능하다. DB는 빠른 성능을 유지하기 위해 데이터 삭제 시 실제로 삭제하는 대신 삭제된 것으로 ‘표시’만 하는 경우가 대부분이다. 따라서 데이터의 복구가 가능하다. 대부분의 공격자들은 데이터를 삭제하기 때문에 삭제된 데이터를 복구하는 것은 분석가에게 매우 중요하다. 이에 월간 안에서는 총 3회에 걸쳐 관계형 DB 중 MySQL의 데이터 복구 포렌식에 대하여 알아본다.


<연재 목차>

1부_MySQL의 현황 및 포렌식적 의미(이번 호)

2부_MySQL InnoDB Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안

3부_ MySQL MyISAM Type의 데이터 파일 구조 분석과 삭제된 레코드의 복구 방안

 

 

정보가 중요한 역할을 하는 시대다. 이 중요한 정보를 체계적이고 효과적으로 관리하기 위한 수많은 DB가 있다. 오라클(Oracle)사의 DB 제품군과 마이크로소프트(Microsoft)사의 MSSQL, IBM사의 DB2, 그리고 SQLite 등의 RDBMS를 비롯하여 Mongo DB, 카산드라, 카우치베이스 등의 NoSQL이 그 예이다. 그러나 수많은 DB들이 모두 시장에서 살아남을 수 있는 것은 아니다. 시장 점유율이 낮은, 즉 사용자가 적은 DB는 분석가들에게는 중요성이 떨어질 수 밖에 없다. 모든 DB들을 일일이 분석하는 것은 결코 쉽지 않은 일이다. 게다가 대부분의 DB들은 지속적으로 수정되거나 새롭게 추가된다. 따라서 분석가들은 최근 가장 많이 사용되고 있는 DB의 현황을 항상 파악하고 있어야 하며, 특히 주로 사용되는 DB들의 저장 방식과 파일 구조 등을 분석하여 유사 시 언제든 대응할 수 있도록 준비해야 한다.

 

[그림 1]은 2012년 5월부터 2013년 5월까지의 오픈소스 기반 DB의 시장 점유율이다. 모든 DB 영역에서의 시장 점유율을 나타내는 자료는 아니지만, 이를 통하여 현재 어떤 DB가 주로 사용되고 있는지를 한눈에 확인할 수 있다. [그림 1]에 따르면 MySQL은 현재 60% 이상의 점유율로 오픈소스 기반 DB 중에서 가장 높은 점유율을 기록하고 있으며 꾸준한 상승세를 보이고 있다. 이로써 디지털 포렌식 관점에서 MySQL의 분석이 얼만큼 중요한 부분인지 짐작할 수 있다.



 

[그림 1] 데이터베이스 시장 점유율(출처: Jelastic 블로그, http://blog.jelastic.com)

 

 

왜 아직도 MySQL인가?



MySQL은 표준 DB 질의 언어 SQL(Structured Query Language)을 사용하는 DB 관리 시스템(Relational Database Management System, RDBMS)이다. 1994년 처음 개발된 이후 오픈소스 라이선스의 무료 DB로 개발되어 왔다. 2008년 선 마이크로시스템스(Sun Microsystems)사에 인수 합병되었으며 2010년에는 오라클사가 선 마이크로시스템스와 함께 MySQL을 인수했다. MySQL의 GUI 버전인 MySQL WorkBench는 오라클에서 개발되었으며, 상업적인 용도로 이용할 경우에는 유료로 사용해야 한다. MySQL은 기본적으로 C, C++, PHP 등 다양한 언어에 대해 API를 제공하고 있으며, 유닉스(Unix) 및 리눅스(Linux), 윈도우(Windows) 등의 운영체제를 지원한다.

 

 

[그림 2] MySQL 로고

 

MySQL은 20여년 동안 발전해 오면서 수많은 기능과 함께 DB로서의 완성도를 높여왔다. 가장 최근에 개발된 MySQL의 저장 방식 중 하나인 InnoDB는 MySQL 내부에서 데이터의 생성 및 수정 등의 과정을 트랜잭션 단위로 처리할 수 있는 기능을 추가했다. 이를 통해 오류에 의해 데이터에 손상을 입은 경우 트랜잭션 로그의 복구를 통해 오류 이전 상태로의 회복이 가능하게 되었다. 이 밖에도 수십 테라 바이트 크기의 데이터를 저장할 수 있는 등 다양한 장점을 갖춘 DB로 거듭나기 시작했다. MySQL의 특징은 무엇보다 오픈소스로 개발되어왔다는 점으로, 수많은 개발자에 의해 가장 최적화된 형태로 개발될 수 있었다. 현재는 오라클에 인수되어 상업적인 용도의 DB도 출시되고 있지만 기존의 오픈소스는 그대로 유지함으로써 수많은 개발자 및 관리자들이 쉽게 접할 수 있다. 또한 MySQL은 표준 SQL을 사용하고 있기 때문에 SQL 문법만 이해하고 있으면 [그림 3]과 같이 MySQL 콘솔 및 GUI 버전 등을 통하여 손쉽게 쿼리를 수행해 원하는 결과값을 얻을 수 있다.

 



[그림 3] MySQL 콘솔(Console)

 

[그림 4]는 MySQL의 GUI 버전인 MySQL WorkBench이다. MySQL WorkBench는 SQL 개발과 관리를 위한 단일 개발 통합 환경을 제공하는 그래픽 기반의 데이터베이스 설계 툴이다. 오라클은 기존의 MySQL GUI를 대체하기 위해 MySQL WorkBench를 제작했는데 사용이 편리해 초보자들도 쉽게 이용할 수 있다.

 



[그림 4] MySQL WorkBench

 

MySQL은 LAMP(Linux-Apache-MySQL-PHP/Perl/Python), 즉 리눅스 운영체제와 아파치(Apache) 서버 프로그램, MySQL, PHP와 같은 스크립트 언어를 통합한 형태로 웹 개발에도 널리 이용되고 있다. 특히 PHP는 MySQL과의 연동이 뛰어나 수많은 웹사이트에 사용되고 있다. 이 밖에도 윈도우 운영체제와 OS X(Mac OS)에서 WAMP, MAMP라는 이름으로 많이 활용되고 있다.

 

오픈소스 라이선스인 MySQL은 비교적 사용이 자유롭기 때문에 누구나 쉽게 DB를 사용할 수 있으며 지속적으로 업데이트 되기 때문에 기존의 사용자들이 계속 MySQL을 사용하도록 하는 매력이 있다. 이처럼 다양한 장점과 매력 때문에 수많은 개발자 및 관리자들은 오랫동안 MySQL을 사용하고 있다.

 

 

MySQL의 포렌식적 의미



MySQL은 일반적으로 정해진 구조에 따라 데이터를 파일에 저장한다. 데이터의 파일 저장 방식에 따라 MySQL은 InnoDB 저장 방식과 MyISAM 저장 방식 등 크게 두 가지로 구분할 수 있다. 물론 이들 외에도 다양한 저장 방식이 있지만 현존하는 대부분의 MySQL DB가 InnoDB와 MyISAM 저장 방식을 사용한다.

 

 

[그림 5] MySQL 설치 폴더

 

InnoDB는 [그림 5]와 같이 MySQL 설치 폴더의 하위 폴더인 ‘data 폴더’의 ibdata라는 파일에 데이터를 저장한다. ibdata 파일에는 InnoDB에 관련된 데이터만 저장되며 MyISAM 저장 방식은 별도로 관리된다.

 



[그림 6] DB명으로 생성되는 폴더

 

대부분의 DB 프로그램들은 데이터를 체계적으로 관리하기 위하여 가장 상위 개념의 데이터 그룹을 생성한다. DB 사용자는 상위 개념의 데이터 그룹을 DB라고 정의하며 일반적으로 데이터의 가장 큰 범주 이름을 DB명으로 정하여 사용한다. DB는 구체적인 데이터를 저장하기 위한 용도로 분류된 여러 개의 테이블을 구성하며 각각의 테이블은 정해진 용도에 따라 각각의 데이터를 테이블 내부에 저장한다.

 

[그림 6]은 MySQL 관리자가 ‘step1’이라는 DB를 생성하였을 경우 시스템에 의하여 ‘step1’이라는 이름의 폴더가 MySQL이 설치된 경로 하위 폴더에 생성된 것이다. DB 내부에 friend와 fristart라는 테이블이 생성되어 있음을 확인할 수 있다.

 

 

[그림 7] MySQL의 ‘Format 파일'

 

[그림 7]은 InnoDB와 MyISAM 저장 방식이 공통적으로 생성하는 frm 확장자 파일을 나타내고 있다. frm 확장자 파일은 테이블명을 파일명으로 사용하며 해당 테이블의 테이블 정보(스키마 정보)를 기록하고 있다. 따라서 frm 파일은 DB를 분석하는데 중요한 역할을 담당하는 파일이라 할 수 있다.

 

이처럼 저장 방식에 따라 각각의 데이터는 정해진 위치에 파일로 저장된다. 이렇게 저장된 데이터는 각각의 파일로 존재하거나 모두 ibdata 파일 안에 존재한다. 따라서 파일 구조에 대한 분석은 디지털 포렌식 관점에서 유용하다.

 

또한 MySQL은 삭제 데이터를 완전히 삭제하지 않기 때문에 파일 내부에는 삭제된 데이터가 남아있다. 이 같은 특징을 이용하여 데이터 복구(Data Recovery)가 가능하며 이를 활용한 데이터 복구 툴이 있다. [그림 8]은 MySQL InnoDB의 복구를 위해 구현되어 있는 실제 Percona의 데이터 복구 툴이다. 비록 데이터 복구 툴의 기능이 제한적이며 사용법이 어렵기 때문에 효용성은 떨어지지만 포렌식 관점에서 삭제된 데이터를 복구하는 것은 매우 중요하기 때문에 데이터 복구 툴에 상당한 포렌식적인 의미를 부여할 수 있다.

 

 

[그림 8] Percona toolkit

 

MySQL의 데이터 복구와 관련해 MySQL의 현황 및 구조 등 기본적인 사항을 살펴보고 이것이 포렌식적으로 어떠한 의미가 있는지 알아보았다. 다음 호에서는 보다 구체적인 MySQL의 구조를 살펴보면서 데이터를 복구하기 위한 방안에 대해 살펴보도록 하겠다.@










  • AhnLab 로고



  • 클라우드분석팀 남궁재웅 연구원




이 정보에 대한 저작권은 AhnLab에 있으며 무단 사용 및 도용을 금합니다.

단, 개인이 비상업적인 목적으로 일부 내용을 사용하는 것은 허용하고 있으나, 이 경우 반드시 출처가 AhnLab임을 밝혀야 합니다.

기업이 이 정보를 사용할 때에는 반드시 AhnLab 의 허가를 받아야 하며, 허가 없이 정보를 이용할 경우 저작권 침해로 간주되어 법적인 제재를 받을 수 있습니다. 자세한 내용은 컨텐츠 이용약관을 참고하시기 바랍니다.

정보 이용 문의 : contents@ahnlab.com


Reentrancy Attack: 블록체인 스마트 컨트랙트의 치명적인 취약점

블록체인 기술이 전 세계적으로 주목받으면서 스마트 컨트랙트(Smart Contract)의 사용이 급격히 증가하고 있습니다. 하지만 그만큼 보안 취약점도 함께 늘어나고 있는데, 그 중에서도 Reentrancy Attack(재진입 공격)은 매우 치명적이고...