보안운영관리/인프라/컨설팅 - 가상화(VMware&Hyper-V)

*화이트햇 스쿨 2기에서 이수한 이론교육 내용을 바탕으로 작성되었습니다.

 

1. Virtual Machine(VM)

 

Virtual Machine(가상 머신)이란?

: 이름 그대로 진짜 컴퓨터가 아닌 가상으로 존재하는 컴퓨터를 의미

 

VM을 사용하는 이유와 장단점

- 자원 최적화: 여러 개의 가상 머신을 한 물리적 서버에서 실행하여 자원을 효율적으로 사용할 수 있음

- 격리: 각 가상 머신은 독립적으로 작동하므로, 하나의 VM에서 발생하는 문제가 다른 VM에 영향을 미치지 않음

- 테스트 및 개발: 새로운 소프트웨어나 업데이트를 테스트할 때, 실제 환경에 영향을 주지 않고 VM에서 테스트가 가능

- 이식성: VM을 사용하면, 전체 운영체제, 애플리케이션, 설정 등을 포함한 가상 머신의 스냅샷이나 이미지를 쉽게 다른 물리적 서버로 이동할 수 있음

- 복구 및 백업: VM의 스냅샷 기능을 사용하여 특정 시점의 VM 상태로 빠르게 복구할 수 있음

- 다양한 OS 환경 지원: 한 물리적 서버에서 여러 운영체제를 동시에 실행할 수 있음

 

VM 한계점

- 성능 오버헤드: VM은 물리적 하드웨어를 애뮬레이션하기 때문에, 가상화 레이어 의존성 때문에 성능 손실이 발생할 수 있음

- 자원의 한계: 물리적 서버의 자원은 한정되어 있기 때문에, 너무 많은 VM을 동시에 실행하면 자원 경쟁이 발생하여 성능이 저하

- 라이선스 비용: 가상화 소프트웨어 또는 관리 도구에 대한 라이선스 비용이 발생(기업용)

 

가상머신 소프트웨어

- Desktop 계열: VMware Workstaion, Hyper-V, Virtual Box, VMware Fusion

- Server 계열: VMware ESXi, VMware vCenter, VMware vSphere

 

하이버바이저란?

- VM을 생성하고 관리하는데 사용되는 가장 기본이 되는 소프트웨어

- 하이퍼바이저는 하드웨어와 가상 머신 간의 인터페이스 역할을 수행하는 중요한 소프트웨어

- 이는 VM이 물리적 하드웨어와 가상 머신 간의 인터페이스 역할을 수행하는 중요한 소프트웨어

- 가상화 구조에서는 하드웨어와 가상 머신이 직접 연결되지 않음

 

하이퍼바이저 유형

- 유형1: 하드웨어 바로 위에서 실행되므로 성능이 우수하며 높은 가상화 효율을 제공, 호스트 운영체제 없이 가상 머신을 관리, 전체적으로 높은 보안 수준을 제공하며 많은 기업 환경에서 사용(VMware vSphere/ESXi, Microsoft Hyper-V)

- 유형2: 호스트 운영체제 위에서 실행되므로 가상화 오버헤드가 있을 수 있음, 호스트 운영체제와 호환성이 뛰어나며 개발 및 테스트 목적으로 사용, 일반적으로 Type 1에 비해 성능은 낮지만 설정과 관리가 간편(Oracle VirtualBox, VMware Workstation)

 

하이퍼바이저 보안

- 보안 관련 고려 사항: 하이퍼바이저의 취약성을 이용하여 가상 머신 내에서 다른 가상 머신 또는 호스트 시스템에 액세스하려는 공격이 가능

 

2. VMware Workstation 실습

 

VMware Workstation 소개

- 여러가지 가상 머신 소프트웨어가 있지만, VMware 사 제품으로 진행

 

가상머신 만들기

- New Virtual Machine Wizard

- Specifiy Disk Capacity: Store virtual disk as a single file, Split virtual disk into multiple files

- Processor 코어 수 조정: 대부분 2개 권장

- Virtualization engine 설정: Virtualize Intel VT-x/EPT or AMD-V/RVI, Virtualize CPU performance counters

- Bridged: 공유기로부터 IP 주소를 가져올 수 있는 경우 사용, 네트워크 호스트 컴퓨터가 가상 시스템과 직접 통신 가능, 호스트 PC와 게스트 PC의 네트워크를 물리적으로 동일한 구성으로 사용

- NAT(기본설정): 외부에서는 볼 수 없고, 호스트 PC를 통해서 외부 네트워크와 통신이 가능

- Host-only: 구성된 가상머신들끼리만 통신이 가능

- 필요에 따라 Subnet IP 값 수정이나 고정 IP 지정 등 원하는 환경을 만들 수 있음

 

3. Docker

 

컨테이너 가상화 기술 개요

- 컨테이너 가상화란 시스템 리소스를 격리시켜 여러 작업을 동시에 수행할 수 있도록 하는 기술

- 이를 통해 개발, 배포, 테스트 등의 프로세스가 단순화되며, 환경 간의 일관성 유지가 가능

- 클라우드 컴퓨팅 환경을 구축하는데 있어서 시스템 환경에 대한 의존성이 없고, 경량화를 통한 속도 및 이식성 향상을 추구하는 Container 기반의 가상화 기법

- 대표적인 플랫폼이 오픈소스 기반의 Kubernetes와 Docker가 있음

 

Docker란 무엇인가?

- Docker는 컨테이너형 가상화 기술을 구현하기 위한 상주 애플리케이션과 이 애플리케이션을 조작하기 위한 명령행 도구 (CLI)로 구성

- 애플리케이션 배포에 특화되어 있음

- 기존 가상화 소프트웨어보다 더 가볍게 동작

- 로컬 환경과 다른 서버의 환경, 개발 환경과 운영 환경을 거의 동등하게 재현할 수 있음

- MSA, 클라우드 아키텍처, DevOps 모두 이러한 컨테이너 기반 개발에서 비롯됨

 

컨테이너형 가상화 기술의 역사

- chroot(1979)
- FreeBSD Jails(2000)

- Solaris Containers(2004)

- LXC(2008)

- Docker(2013)

- Kubernetes(2014)

 

OCI에서 제시하는 표준 컨테이너 5개 원칙

- 표준 동작: 표준 컨테이너 도구들을 이용해서 컨테이너의 생성, 시작, 정지가 가능해야 함 / 표준 파일 시스템 도구를 통해서 커네이너의 스냅샷과 복사가 가능해야 함

- 내용 중립성: 표준 컨테이너는 컨테이너가 담고 있는 애플리케이션의 종류에 상관 없이 표준 동작들이 동일하게 동작해야 함

- 인프라 중립성: 표준 컨테이너는 OCI 지원 인프라라면 종류에 상관없이 컨테이너 실행이 가능해야 함

- 자동화를 위한 설계: 표준 컨테이너 내용과 인프라 종류에 상관없이 동일한 표준 동작을 지원하기 때문에 자동화가 용이함

- 산업 수준의 배포: 표준 컨테이너는 기업 규모에 상관없이 산업 수준의 배포가 가능해야 함

 

Docker의 보안 관련 개념과 중요성

- 컨테이너: 각 이미지와 인스턴스는 별도로 보안 및 모니터링 필요

- 도커 데몬: 호스트하는 컨테이너를 안전하게 유지하기 위해 보안이 필요

- 네트워크 및 API: 컨테이너 간의 통신을 용이하게 함

- 데이터 볼륨: 컨테이너 외부에 존재하는 다른 저장 시스템

 

도커 엔진의 기본 보안

- 도커는 네임스페이스를 사용하여 작업 공간 프로세스 ID, 네트워크, 프로세스 간 통신, 마운트 등을 격리함

- 이로 인해 컨테이너 간에 격리가 제공됨

- 또한 cgroups를 사용하여 컨테이너가 사용할 수 있는 CPU나 메모리 양을 제한

 

리눅스 커널 기능

- 도커는 기본적으로 제한된 세트의 기능으로 컨테이너를 시작

- 컨테이너 내에서 실행되는 모든 프로세스에 "root" 권한이 부여되지 않음을 의미

 

4. 인프라와 아키텍처

 

Infra(인프라)

- 일반적으로 기반 시설 또는 기본 시스템을 의미

- 소프트웨어와 IT 산업에서 인프라는 종종 기본적인 시스템, 서비스, 기능 및 기능을 지원하는 물리적 및 가상 리소스를 의미(하드웨어 인프라, 소프트웨어 인프라, 네트워크 인프라, 클라우드 인프라, 가상화 인프라)

 

IaC(Infastructure as Code)

- IT 인프라의 관리 및 구성을 자동화하기 위해 코드와 소프트웨어 개발 기술을 사용하는 프로세스 및 방법론

- IaC는 소프트웨어 코드처럼 인프라를 정의하고 관리하게 함

- 이 접근법을 통해 개발자와 시스템 관리자는 데이터 센터의 물리적 요소나 OS 설정, 서버 구성 등의 인프라 구성 요소를 자동화된 방식으로 관리

 

아키텍처(Architecture)

- 시스템 구성 및 동작 원리를 나타내는 것

- 구성 요소 간의 관계 및 시스템 외부 환경과의 관계를 묘사하는 것

- 시스템 구성 요소에 대한 설계 및 구현을 지원하는 수준을 기술하는 것

- 요구 사양 및 시스템 수명 주기를 고려하는 것

- 시스템의 전체적인 최적화를 목표로 하는 것

 

IT 인프라 아키텍처

- IT 인프라 아키텍처는 조직의 IT 리소스와 서비스의 기반 구조를 설계하는 방식을 의미

- 이는 하드웨어, 네트워크, 미들웨어, 데이터 저장 방법 및 가상화 솔루션 등을 포함

- 목적은 안정적이고 확장 가능하며 효율적인 IT 환경을 구축하는 것

- 비즈니스 요구 사항을 지원하고 변화에 대응하기 위해 기본적인 IT 리소스를 어떻게 구성하고 연결할지를 결정하는 기술

 

소프트웨어공학에서의 아키텍처

- 소프트웨어 아키텍처는 시스템을 구성하는 주요 컴포넌트와 이 컴포넌트 간의 관계를 정의

- 아키텍처는 소프트웨어의 기본 구조와 그 구조의 기술적 결정 사항들을 설명

- 목적은 소프트웨어의 안정성, 확정성, 성능, 재사용성 및 유지 보수성을 보장하는 것

- 아키텍처는 또한 개발 팀 간의 협업을 촉진하며, 높은 수준의 설계 문서로서 프로젝트 방향성을 제공

 

아키텍처 간의 연관성

- IT 인프라 아키텍처는 종종 소프트웨어 아키텍처의 기반이 됨

- 소프트웨어의 아키텍처는 IT 인프라의 선택과 구성에 영향을 줄 수 있음

- 두 아키텍처는 각자 독립적인 목적을 가지고 있지만, 종종 서로 상호작용하며, 하나의 시스템 또는 솔루션을 구축할 때 함께 고려되어야 함

 

Monolithic Architecture

- 비즈니스 로직, DB, UI 등을 하나의 패키지에 담아 빌드하고 배포하는 아키텍처

- 마이크로서비스 아키텍처의 반대 개념

- 빠르고 쉽게 서비스를 구성할 수 있어 적은 비용으로 서비스를 출시 가능

- 코드가 많아지고 복잡해짐에 따라 모놀리틱의 아키텍처의 한계점이 부각됨

- 부분 장애가 전체 서비스의 장애로 확대될 수 있음

- 여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 떄문에 서비스 수정에 대한 영향도 파악이 어려워 수정 개발기간의 지연을 야기함

- 소스코드 테스트를 위한 비용 증가

- 한 Framework와 언어에 종속적

 

MSA

- 마이크로서비스 아키텍처란 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처

- 어플리케이션을 핵심 기능 별로 세분화하고 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있음

- 서비스는 각자 별도의 프로세스에서 실행되며, HTTP 자원 API 같은 가벼운 매커니즘으로 통신하며 하나의 애플리케이션을 만듦

- 각자 가진 네트워크 기능으로 통신할 수 있음

- 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화된 절차에 따라 독립적으로 배포 가능

- 서로 다른 프로그래밍 언어나 서로 다른 DB를 사용할 수도 있음

 

5. 쿠버네티스 (k8s)

 

History

- 조타수 또는 조종사를 뜻하는 그리스어에서 유래했으며, 쿠버네티스의 약어인 k8s는 k와 s사이에 8글자가 있다는 뜻

 

정의

- 쿠버네티스는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 플랫폼

 

목적

- 다수의 노드(서버)에서 컨테이너의 배포 및 관리를 자동화하여, 애플리케이션의 확장성과 장애 복구를 향상시킴

 

기능

- 자동 복구

- 롤링 업데이트

- 스케일링

- 로드 밸런싱

 

Kubernetes 구성 요소

- Master Components: API Server, etcd, Scheduler, Controller Manager

- Node Components: Kubelet, Kube Proxy, Container Runtime

 

Container Orchestration

쿠버네티스의 오케스트레이션 범위

- 컨테이너 스캐줄링: 클러스터 내에서 컨테이너가 가장 적합한 노드에서 실행되도록 스케줄링

- 서비스 디스커버리 및 로드 밸런싱: 쿠버네티스는 서비스 디스커버리와 로드 밸런싱을 제공하여, 서비스간의 커뮤니케이션을 간편하게 함

- 자동화된 롤아웃 및 롤백: 쿠버네티스는 어플리케이션 배포 시 장애가 발생하면 롤백을, 업데이트 시는 롤아웃을 자동으로 수행

- 자동 스케일링: 리소스 사용량에 따라 자동으로 어플리케이션을 스케일링 할 수 있음

- 자동 복구: 쿠버네티스는 실패한 컨테이너를 재시작하고, 노드가 다운되면 다른 노드에 컨테이너를 재스캐줄링함

- 시크릿 및 설정 관리: 시크릿 및 어플리케이션 설정을 관리할 수 있으므로, 코드와 별도로 중요한 정보를 보관할 수 있음

- 스토리지 오케스트레이션: 어플리케이션에 따라 스토리지를 자동으로 마운트할 수 있음

 

범위 밖

- 하드웨어 구성 및 관리

- 네트워크 구성

 

Scale-out vs. Scale-up

- Scale-out(수평확장): 더 많은 서버를 추가하여 시스템의 용량을 확장 / 쿠버니티스에서는 자동으로 노드를 추가하여 애플리케이션을 확장할 수 있음

- Scale-up(수직확장): 기존의 서버에 더 많은 리소스(CPU, 메모리 등)를 추가하여 시스템의 용량을 확장 / 리소스의 한계에 도달하면 확장이 어려울 수 있음

 

K8s Security

- 네트워크 폴리시: 특정 파드 간의 통신 흐름을 제어하여, 불필요한 네트워크 액세스를 차단

- 롤 기반 접근 제어: 사용자와 시스템 구성요소의 권한을 세말하게 관리하여, 최소 권한 원칙을 준수

- 시크릿 관리: 중요한 정보를 안전하게 저장하고 사용

- 이미지 보안: 안전하지 않은 컨테이너 이미지의 사용을 방지하고, 이미지의 무결성을 보장

- 파드 보안 정채기 파드가 실행될 때의 보안 컨텍스트를 제한

- 네트워크 세그멘테이션: 클러스터 내의 네트워크를 분리하여, 공격 범위를 축소

- 로그 및 모니터링: 보안 사건을 신속하게 탐지하고 대응하기 위해 로그를 수집하고 모니터링

 

6. DevOps, CI/CD

 

애자일 정신

- 애자일 소프트웨어 개발 선언과 12가지 원칙

 

DevOps 소개

- 정의

  - DevOps는 개발과 운영의 합성어로, 소프트웨어 개발과 IT 운영의 협력과 통합을 강조하는 개발 방법

  - 이는 개발 및 운영 팀간의 커뮤니케이션과 협력을 통해 소프트웨어 제품과 서비스를 더 빠르게 제공하는 것이 목표

- DevOps의 원칙

  - 문화의 변화: 조직 내에서 개발자와 운영 팀 간의 협력과 소통을 강조

  - 자동화: 배포 프로세스의 자동화를 통해 빠른 피드백과 빠른 배포를 가능케 함

  - 지속적 통합 및 배포: 코드 변경 사항을 지속적으로 통합하고 배포하여 오류를 빠르게 찾고 해결

  - 측정 및 모니터링: 성능 지표를 측정하고 모니터링하여 지속적인 개선을 추구

 

DevOps의 목표와 이점

- 목표: 개발과 운영의 효율성을 최적화하여 빠르고 안정적으로 고객에게 가치를 전달하는 것

- 이점

  - 빠른 시장 진입: 빠른 배포로 인해 제품을 더 빨리 출시할 수 있음

  - 향상된 제품 품질: 지속적인 피드백과 테스팅으로 제품 품질을 향상

  - 효율적인 운영: 자동화와 효율적인 프로세스로 운영 비용을 절감

- DevOps 문화와 실천 방법

  - 협력, 공유, 책임, 투명성을 중시하는 문화를 구축

  - 지속적 통합, 지속적 배포, 지속적 피드백, 지속적 학습 및 개선을 통해 DevOps 문화를 실천해야 함

  - 즉, 조직 구성원 개개인의 능력과 동기부여 또한 매우 중요한 요소

 

Continuous Integration의 정의와 이점

- 정의

  - Continuous Integration(CI)은 개발자들이 자주 자신의 코드 변경사항을 중앙 저장소에 통합하는 개발 방법론

  - 이 과정에서 자동화된 빌드와 테스트가 수행되어 빠르게 오류를 찾고 수정할 수 있음

- 이점

  - 오류 감소: 빠른 피드백 사이클로 인해 오류를 빠르게 발견하고 수정할 수 있음

  - 품질 향상: 지속적인 테스트와 통합으로 소프트웨어 품질이 향상

  - 생산성 향상: 자동화된 프로세스로 개발자의 생산성이 향상

- Continuous Delivery(CD)

  - 개발된 소프트웨어를 사용자에게 안정적으로 배포할 수 있도록 지속적으로 준비하는 접근 방식

  - 최초 세팅이 필요하기 때문에 어느 정도 수동적

- Continuous Deployment(CD)

  - 모든 변경 사항이 자동적으로 테스트되고, 프로덕션 환경으로 배포되는 접근 방식

  - 이 방식은 완전한 자동화를 필요

 

CI/CD 도구

- Jenkins, Travis CI, CircleCL 등

 

모니터링과 로깅

- 데이터 가시성 확보의 중요성 

  - 데이터 가시성은 조직이 데이터를 효과적으로 모니터링하고 분석할 수 있게 해주어, 시스템의 성능과 보안 상태를 지속적으로 평가할 수 있게 함

  - 이를 통해 조직은 보안 위협을 신속하게 탐지하고 대응

- 보안 위협 탐지

  - 실시간 데이터 모니터링으로 비정상적인 행동이나 패턴을 신속하게 탐지함

- 응답 시간 최소화: 데이터 가시성을 통해 보안 사고 발생 시 신속하게 대응하고, 피해를 최소화

 

테스트 자동화

- 테스트 자동화는 개발 프로세스의 효율성과 품질을 향상시키며, 보안적 측면에서도 중요한 역할을 함

  - 보안 취약점 탐지: 자동화된 테스트를 통해 보안 취약점을 조기에 발견하고 수정할 수 있음

  - 보안 위반 감소: 정기적이고 지속적인 테스트로 인해 보안 위반의 가능성이 감소함

- 테스트 자동화 도구 예시

  - Selenium, JUnit, TestNG, Appium 등

- 보안적 측면에서의 도구 예시

  - 정적 분석 도구: 소스 코드의 보안 취약점을 분석함

  - 동적 분석 도구: 실행 중인 애플리케이션의 보안 취약점을 탐지함

 

7. DevOps + Security (DevSecOps)

 

DevOps for Zero Trust

- 제로 트러스트: 제로 트러스트는 모든 사용자와 시스템이 신뢰할 수 없다고 가정하고, 모든 네트워크 트래픽에 대해 검증과 검사를 수행하는 보안 모델

- 제로 트러스트의 필요성

  - 현대의 다양하고 복잡한 사이버 위혐 환경에서, 기존의 경계 기반 보안 접근 방식은 더 이상 효과적일 수 없음

  - 제로 트러스트 모델은 이러한 위협 환경에서 조직의 정보를 보호할 수 있는 방법을 제공

- 제로 트러스트의 원칙

  - 신뢰하지 않기: 모든 사용자와 시스템은 신뢰할 수 없다고 가정

  - 검증: 모든 요청은 정당한지 검증

  - 최소 권한 부여: 사용자와 시스템에는 필요한 최소한의 권한만 부여함

- DevOps 환경의 보안: DevOps 환경에서의 보안은 개발과 운영의 지속적인 통합과 배포 과정에서의 정보 보호를 의미

- 공격자의 대상과 이유

  - 공격자들은 파이프라인을 대상으로 하여, 조직의 중요 정보를 탈취하거나 시스템을 목표

  - 이는 DevOps 환경이 지속적인 배포와 자동화에 의존하기 때문

- 보호를 위한 접근 방식

  - DevOps 환경을 보호하기 위해서는, 보안을 개발 및 배포 파이프라인의 초기 단계부터 통합하여, 지속적인 모니터링과 자동화된 보안 검사를 수행해야 함

 

- 비밀 및 인증서 관리의 중요성

  - 비밀 관리의 중요성: 비밀 및 인증서 관리는 시스템과 데이터의 보안을 유지하기 위해 필수적 / 이는 인증과 암호화를 통해 정보의 무결성과 기밀성을 보장

  - 비밀 및 인증서 관리의 모범 사례: 비밀 관리는 민감한 정보의 노출을 방지하고, 비인가 접근으로부터 시스템을 보호하는데 중요한 역할을 함

 

- DevOps 환경 보안에 대한 모범 사례

  - 감사 로그의 적용

  - 소프트웨어 공급망 보호

  - IaC 템플릿 검사의 자동화

  - 승인된 워크플로의 자동화

- 애플리케이션을 전체 프로덕션에 배치하기 전에 Develop, Security 및 Operations 도메인에서 프로덕션 릴리스에 대한 MVP(최소 실행 가능한 제품)가 각 분야의 요구 사항을 충족하는지 확인

- MVP는 조직의 목표, 문화 및 산업에 따라 다르지만, 신속한 릴리스, 보안/안전, 프로덕현 성능 및 안정성에 대한 요구 사항의 균형을 수시로 조정해야 함

- 정확한 지침을 수립

  - 보안 디자인: 보안에 초점이 맞춰진 디자인 방식, 위협 모델링 기술을 사용하는 것도 포함

  - 시큐어 코딩: 실제 구현의 보안 유효성을 검사, 여기에는 정적 및 동적 분석과 같은 도구를 사용하여 버그 수정 및 보안 취약점 개선 작업이 포함

- 보안 환경: 기본 인프라 구성이 패치, 구성 등에 대한 모범사례를 따르는지 확인

 

보안 문화 구축

- 보안에 있어서 가장 정의하기 어렵고 까다로운 것이 "사람"

  - 인간의 행동은 예측이 불가능하며, 이로 인해 보안에 다양한 복잡성과 위험이 발생

  - 이러한 인간 요소의 불확실성을 최소화하기 위해 교육과 훈련이 필수적

  - 교육과 훈련을 통해 개발자와 보안 관리자 뿐만 아니라, 모든 구성원들에게 올바른 행동 지침을 제시하고 보안 인식을 제고할 수 있음

  - 이를 통해 조직 전체의 보안 건전성을 향상시킬 수 있으며, 보안 위협에 대한 조직의 적절한 대응 능력을 강화할 수 있음

 

마무리

가상화 기술을 바탕으로 점점 복잡해지고 정교해지는 클라우드 컴퓨팅 환경에서 '클라우드 네이티브' 관점에서 보안을 이해하고, 진정한 의미(마케팅이 아닌 기술)의 DevSecOps(Zero Trust)를 달성하기 위해서는 단순한 네트워크 레벨에서의 보안기술(IPS/IDS)과 안티바이러스 기술들 뿐만 아니라, 새로운 사각지대가 어디인지, 새로운 보안 취약성 및 공격 경로는 어디가 될지를 사전에 파악하고 빠르게 대처하는 것이 핵심이다.

 

*클라우드 네이티브: 특정 인프라에 종속적이지 않고, 물리적인 위치에 상관 없이, 클라우드 환경을 기반으로 애플리케이션을 설계, 구축, 관리할 때의 소프트웨어 접근 방식