検索結果

これまでのシリーズ記事では、インフラ、パイプライン、運用手法など、さまざまな観点からアプリケーションのデプロイについて取り上げてきました。しかし、セキュリティはそれらとは切り離されたものではなく、ライフサイクル全体に浸透する基盤レイヤーとして理解する必要があります。この考え方は、DevOps Tools Engineer試験のObjective 704.1「Cloud Native Security」にも反映されています。 このObjectiveでは、クラウドネイティブ環境特有の原則、リスク、そしてその軽減策について扱います。具体的には、コンテナ化されたアプリケーションの保護、分散システムにおけるID管理とアクセス制御、API保護、さらにサードパーティ依存関係がもたらす影響などが含まれます。クラウドネイティブアーキテクチャへの移行により、新たな攻撃対象領域、動的なワークロード、複雑な依存関係チェーンが生まれ、従来とは異なるセキュリティの考え方が求められるようになっています。 クラウドネイティブでは、セキュリティを独立した分野として扱うのではなく、開発・運用ワークフローへ直接組み込むことが重視されます。この考え方は一般的に「DevSecOps」と呼ばれています。これには、CI/CDパイプラインへのセキュリティチェックの自動化、脆弱性スキャンの継続実施、最小権限アクセスの徹底、サービス間通信の暗号化と認証の確保などが含まれます。 コアITインフラコンポーネントは、単にアプリケーションをデプロイするためだけでなく、環境全体にセキュリティを適用する上でも中心的な役割を担っています。現代のアーキテクチャでは、事後対応型の対策に頼るのではなく、各インフラ層にセキュリティを組み込み、「セキュア・バイ・デザイン」を実現することが求められています。 コンピュートリソース 仮想マシン、コンテナ、サーバーレス関数などのコンピュートリソースは、アプリケーションの実行基盤であり、攻撃対象となりやすいレイヤーです。これらを保護するには、OSのハードニング、不要パッケージの削減、最小権限でのプロセス実行、継続的なセキュリティアップデートが必要です。コンテナ環境では、ランタイム分離やセキュリティプロファイルなどの追加対策によって、権限昇格やワークロード間の不正アクセスを防止します。 ネットワークコンポーネント ネットワークコンポーネントは、システム間通信を定義するものであり、公開範囲を制御するために不可欠です。仮想プライベートクラウド（VPC）やサブネットによるネットワーク分離を実装することで、機密リソースを外部アクセスから隔離できます。ファイアウォールやパケットフィルタリングによって、送受信トラフィックに厳格なルールを適用し、不正接続のリスクを低減します。適切に設計されたネットワークは、環境内での横方向移動（ラテラルムーブメント）を制限し、許可された通信経路だけを利用可能にします。 ロードバランサーやアプリケーションゲートウェイは、インフラへの制御された入口として機能します。セキュリティ面では、TLSによる通信暗号化の強制、レート制限によるDoS攻撃対策、悪意あるトラフィックのフィルタリングに重要な役割を果たします。また、内部サービスを抽象化し、バックエンドシステムを直接公開しないことで、攻撃対象領域を縮小します。 ストレージシステム データベースやオブジェクトストレージを含むストレージシステムでは、データの機密性と完全性を確保する必要があります。そのために、保存時暗号化（Encryption at Rest）、厳格なアクセス制御、アクセスパターンの継続的な監視が行われます。ストレージサービスを直接公開しないこと、そして細かな権限制御を行うことは、情報漏えいや不正改ざんを防ぐ上で重要です。 IAM Identity and Access Management（IAM）は、安全なインフラにおいて最も重要なコンポーネントの一つです。IAMは認証と認可を管理し、ユーザーやサービスが必要なリソースのみにアクセスできるようにします。最小権限の原則やロールベースアクセス制御（RBAC）を適用することで、認証情報の悪用リスクを低減し、アカウント侵害時の影響範囲を限定できます。 セキュリティリスク 現代のITインフラにおける一般的なセキュリティリスクは、システムの公開範囲、複雑性、そして相互接続されたアーキテクチャに起因します。環境がクラウド、コンテナ、API、サードパーティサービスへと分散するにつれ、攻撃対象領域は大幅に拡大しています。これらのリスクを理解することは、可用性・完全性・機密性を守るための効果的な対策設計に不可欠です。 環境の脆弱性悪用 最も一般的なリスクの一つが、OS、アプリケーション、公開サービスに存在する既知の脆弱性を悪用する攻撃です。これらの脆弱性は通常、CVE IDやスコアによって管理され、対処優先度の判断に利用されます。最も効果的な対策は、強力なパッチ管理プロセスを維持し、セキュリティアップデートを迅速に適用することです。定期的な脆弱性スキャンや継続的監視も、リスク低減に役立ちます。 もう一つの一般的な脅威はブルートフォース攻撃です。これは、繰り返しログイン試行を行い認証情報を推測する攻撃です。強力なパスワードポリシー、レート制限、多要素認証（MFA）の導入が有効な対策です。アカウントロック機構やログイン異常の監視も重要です。 DoSおよびDDoS攻撃は、システムを過負荷状態にし、正規ユーザーがサービスを利用できなくする攻撃です。これらはコンピュート、ネットワーク、アプリケーション層を標的にします。ロードバランサー、自動スケーリング、Web Application Firewall（WAF）、アプリケーションゲートウェイなどが有効な対策です。レート制限やトラフィックシェーピングも、悪意あるトラフィック急増への対応に役立ちます。 誤設定されたネットワーク制御も重大なリスクです。過度に緩いファイアウォールルールや公開サービスは、内部システムへの不正アクセスを許してしまいます。パケットフィルタリング、ネットワーク分離、最小権限アクセスの適切な適用が不可欠です。 アプリケーションレイヤー攻撃 保護されていないAPIも大きな攻撃経路となります。適切な認証、認可、レート制限がなければ、攻撃者は機密データへアクセスしたり、サービスを悪用したりできます。強力な認証、入力検証、レスポンス情報の最小化、厳格な権限制御が必要です。CORSヘッダーやCSRFトークンも有効な対策です。 さらに、バッファオーバーフローや、内部情報を漏えいする過度に詳細なエラーレポートなど、ソフトウェアレベルの問題も存在します。安全なコーディング、入力検証、適切なエラーハンドリング、定期的なコードレビューやセキュリティテストが防御強化に役立ちます。 アプリケーションセキュリティリスクは、ソフトウェアの設計・実装・公開方法に起因します。アプリケーションはユーザーとインフラの主要な接点であり、攻撃対象になりやすい層です。 代表的な脆弱性の一つがSQLインジェクションです。攻撃者が入力フィールドを操作し、意図しないデータベースクエリを実行させる攻撃です。パラメータ化クエリやPrepared Statementの利用、厳格な入力検証が有効です。ORMフレームワークの利用もリスク低減に役立ちます。 クロスサイトスクリプティング（XSS）も広く知られた問題です。悪意あるスクリプトをWebページへ注入し、ユーザーのブラウザで実行させる攻撃です。適切な出力エンコード、入力サニタイズ、Content Security Policy（CSP）などのセキュリティヘッダーが有効です。 サプライチェーン脆弱性 依存関係やサプライチェーンのリスクも近年重要視されています。多くのアプリケーションは外部ライブラリやコンポーネントに依存しており、それらに脆弱性や悪意あるコードが含まれる可能性があります。 CVEデータベースによる既知問題の監視、依存関係の検証、更新管理は重要な対策です。組織は、信頼できる検証済みコンポーネントのみを本番環境で利用するよう、積極的な依存関係管理を行う必要があります。 パッチ適用、アクセス制御、ネットワーク分離、監視、安全な開発手法を組み合わせることで、多層防御（Defense in Depth）を実現できます。このレイヤードセキュリティモデルにより、一つの防御策が破られても、他の対策がインフラを守り続けることができます。 暗号化・認証・アクセス制御：安全な認証と認可の基盤 公開鍵暗号方式（非対称暗号）は、現代セキュリティの基盤技術です。公開鍵と秘密鍵のペアを利用し、公開鍵は自由に配布できる一方、秘密鍵は厳重に保護されます。一方の鍵で暗号化したデータは、もう一方の鍵でしか復号できません。 この仕組みにより、機密性、完全性、認証などの重要なセキュリティ特性が実現されます。TLSのようなプロトコルでは、クライアントとサーバー間の安全な接続確立に利用されています。 デジタル証明書は、この公開鍵暗号を基盤として、公開鍵とIDを結び付ける仕組みです。代表的なのがX.509証明書で、ドメインや組織情報を含み、認証局（CA）によって署名されます。この署名により、公開鍵が本当に対象のIDに属していることを確認できます。 認証（Authentication）と認可（Authorization）は密接に関係していますが、異なる概念です。認証は「本人確認」、認可は「その主体が何をできるか」を決定します。 OAuth2は、ユーザー認証情報を公開せずにアプリケーションへリソースアクセス権を委任する仕組みとして広く利用されています。OpenID Connect（OIDC）はOAuth2へ認証機能を追加したものです。SAMLは企業環境でのフェデレーション認証やシングルサインオン（SSO）に利用されています。 ユーザー認証情報の管理も極めて重要です。パスワードは平文保存してはならず、ハッシュ化とソルト化を用いて保護する必要があります。強力なパスワードポリシー、認証情報ローテーション、Secrets Managerなどによる安全な保管も重要です。しかし、パスワードだけでは十分ではありません。 高度な認証技術として、二要素認証（2FA）や多要素認証（MFA）があります。これらは、「知っているもの（パスワード）」「持っているもの（デバイス）」「本人固有のもの（生体情報）」を組み合わせます。OTPやTOTPを利用する認証アプリも一般的です。これらは、認証情報漏えい時でもアカウント侵害リスクを大きく低減します。 これらの技術と概念は、安全なID管理と通信基盤の中核を成しています。強力な暗号基盤、標準化された認証プロトコル、現代的な認証情報管理を組み合わせることで、組織は複雑化する環境においても、ユーザーIDを保護し、安全なアクセスを実現できます。 そして忘れてはならないのが、LPIがDevOps Tools Engineer version 2.0試験向けの公式Learning Materialsを提供していることです。これらの教材は包括的かつ無料で利用でき、試験範囲に完全対応しているため、学習を進める上で非常に優れたリファレンスとなります。 << このシリーズの前回の記事を読む | 次回の記事を読む >>

私がMatrixについて語るとき、それは単なる「また別のメッセージングアプリ」を紹介しているわけではありません。私は、中央集権型プラットフォームが抱える構造的な問題を解決するための通信プロトコルについて話しています。 この議論は、もはや抽象的なものではありません。政治的圧力、Chat Controlのような規制提案、そして巨大通信事業者の統合が進む中で、中央集権化は技術的にも社会的にも大きなリスクとなっています。 Linux Day Italia 2025のイベントの一つであるLinux Day Palermoにおいて、私は「なぜMatrixがこのように設計されたのか」「どのように動作するのか」、そして「なぜ分散化がプライバシーとデジタル自立性に不可欠になりつつあるのか」について解説しました。 中央集権型システムは予測可能な形で失敗する 現在主流のメッセージングプラットフォームは、すべて同じモデルを共有しています。単一の事業者がインフラ、サーバー、ロジック、そしてメタデータを所有しているのです。 これは次のことを意味します。 データ保持、メタデータ、アクセス権、相互運用性に関する方針を企業側が決定する アップデートによってユーザーの期待が損なわれる可能性がある 障害や制限が瞬時に世界中へ波及する システムに中央管理点が存在するため、法的要求がすべての利用者へ同時に影響する 暗号化だけでは、中央集権的なアーキテクチャの問題を補うことはできません。通信経路、サーバーロジック、あるいは認証システムが単一の事業者に依存している場合、信頼モデル全体もその事業者に依存することになります。 Matrix：プラットフォームではなく、まずプロトコル Matrixは、この問題に対してまったく逆のアプローチを取っています。Matrixは、イベントベースのリアルタイム通信のためのオープンプロトコルを定義しています。 メッセージ、状態更新、参加イベント、暗号鍵など、すべてが署名付きイベントとして表現され、複数サーバー間で複製されます。 主な特徴は以下の通りです。 Federation（連携）独立したサーバー同士が、中央管理者に依存せずサービス（ルーム）を同期する エンドツーエンド暗号化OlmおよびMegolmを基盤とした強力なプロトコルにより、非同期かつマルチデバイスの会話を保護する オープン実装クライアントとサーバーの両方がオープンソースであり、相互運用性は「理想」ではなく「必須要件」となっている ポータブルなアイデンティティアカウントはサービス提供企業ではなく、自分で選んだサーバー上に存在する Matrixを単なる「チャットアプリ」ではなく、「イベント複製システム」として理解すると、その柔軟性や耐障害性がより納得できるようになります。 マーケティング用語を超えたセキュリティ Matrixにおけるエンドツーエンド暗号化は、クライアント側で実施されます。サーバー管理者が閲覧できるのは暗号化済みデータのみです。 デバイス認証、クロスサイン、セキュアな鍵バックアップによって、マルチデバイスメッセージングにありがちな弱点も軽減されています。 講演で特に強調した点の一つは、「暗号化はMatrix内部でのみ有効」ということです。外部システムへメッセージをブリッジする場合、意図的にエンドツーエンド暗号化の保証を崩すことになります。 ブリッジは相互運用性のためには非常に便利ですが、高いセキュリティを求める通信手段として扱うべきではありません。 実際のFederation 分散型システムでは、参加するサーバー間でルーム状態が共有されます。各サーバーは署名を用いてイベントを保存・検証します。 仮にあるサーバーが停止しても、他のサーバーがルーム履歴や状態を保持しています。この設計により、単一障害点が排除され、検閲・障害・一方的なポリシー変更に強い通信基盤が実現されています。 政府機関、大学、ハッカースペースなど、多くの組織にとっての本当の価値はここにあります。自分たちのインスタンスを運用し、自分たちのポリシーを維持しながら、世界中と通信できるのです。 Matrixのホスティングは思っているより簡単 多くの人は、自前サーバーの運用は複雑だと思っています。しかし、システム管理の経験がある人にとっては比較的簡単です。 コンテナを使ってSynapseインスタンスをデプロイし、適切なポート設定とリバースプロキシを構成するだけで、Federationへ参加できます。 さらに、より高性能あるいは軽量な実装も利用可能です。 ここでMatrixは現実的な選択肢になります。まずは公開サーバーから始め、技術力が付いたら移行することもできますし、小規模コミュニティ向けに独自インスタンスを立てることもできます。 このプロトコルは、小規模から大規模まで柔軟にスケールします。 Palermoで寄せられた主な質問 セッションでは、いくつか技術的な質問がありました。 「WhatsAppの暗号化はどうなのか？」 暗号技術自体は優秀です。しかし、システム全体は依然として中央集権型です。実際、WhatsAppで発見された脆弱性によって、文字通り数十億人分の情報が危険にさらされたことがあります。 利用者はサーバーアーキテクチャを確認することも、ポリシーへ影響を与えることもできません。 「ブリッジは攻撃対象領域を広げるのか？」 はい。ブリッジはメッセージを変換するために内容を読み取る必要があります。そのため、利便性のために使うべきであり、高度なセキュリティが必要な用途には向いていません。 全体として言えるのは、分散化は脅威モデルを変化させるということです。リスクそのものを消し去るわけではありませんが、制御権を利用者や組織へ取り戻すことができます。 なぜMatrixは正しい方向性に思えるのか Matrixだけが分散型通信技術ではありません。しかし、現在もっとも成熟し、実用的な選択肢の一つです。 透明性、移植性、ユーザー主体性、共同開発といったオープンソースの価値観に合致しており、特定プラットフォームへの依存から脱却できます。 まずはシンプルに始めてみるとよいでしょう。アカウントを作成し、Elementなどのクライアントを利用して、いくつかのルームへ参加してみてください。 慣れてきたら、自分自身のホームサーバーを運用してみましょう。 通信が単一事業者に依存しなくなった瞬間、その価値を実感できるはずです。 分散化は、もはや一部の理想主義者だけのものではありません。安全で長期的な通信を実現するための、唯一持続可能なアーキテクチャになりつつあります。 Matrixは、その原則が「いつか」ではなく、「今」実際に機能することを示しています。 この記事の元となったイタリア語の動画はこちらです。「Matrix vs ChatControl | Morrolinux ‪@FreeCircle‬ | Linux Day Palermo 2025」

本記事は、現代におけるデータ収集をテーマにした連載の最終回です。最後は、企業の管理者による従業員の追跡について取り上げます。 この連載の読者の多くは、私と同様に「ナレッジワーカー」、いわゆる「クリエイティブクラス」に属しており、製造ライン上の部品のように単純に追跡されることはないと考えているかもしれません。しかし実際には、非常に多くの労働者がきわめて侵襲的な監視の対象となっています。 こうした広範な追跡は、雇用主との契約の一部として合法的に行われるものであり、以下のような内容が含まれる場合があります。 キーストローク（キー入力）の記録 画面の監視 インターネット利用状況 メールの内容 ソフトウェアの利用状況 通話時間および通話内容 ボイスメールやインスタントメッセージ GPSによる位置情報の追跡 入退館時のバッジ記録 ビデオ監視 指紋や顔認識スキャンなどの生体情報 もちろん、これらすべてがすべての従業員に対して使用されるわけではありません。たとえば、紙の書類からデータベースへ入力する業務では、作業速度や長時間の休憩の有無を確認するためにキーストロークの記録が使われることがあります。一方で、トラック運転手（郵便配達員を含む）の場合は、業務の進行状況や業務外利用の有無を把握するためにGPSが利用されることが一般的です。 ある企業は、マウスやキーボードの操作を追跡するサービスを提供しており、次のように顧客へ訴求しています。「従業員に関する重要な疑問に答えます：誰が仕事への関与を失っているのか？誰が遅れを取っているのか？誰が燃え尽きのリスクにあるのか？リモートワークやハイブリッド勤務は生産性にどのような影響を与えているのか？」（最後の問いは、集計データに基づく一般的な分析です。） また、ある調査で高評価を得た企業は、非常に幅広いユーザー活動を追跡しています。「画面の録画、従業員PCのリアルタイム監視、メールの追跡、キーストロークの記録、さらにはZoomセッションに至るまで、多岐にわたる活動を追跡します。」 なお、米国では企業側から隔離されている重要な個人情報の分野があります。それは健康情報です。HIPAA（医療保険の相互運用性と説明責任に関する法律）により、従業員は雇用主が提供する医療保険を利用しても、診断内容や治療内容が雇用主に知られることはありません。 << このシリーズの前の記事を読む | 次の記事を読む >>

Kubernetesは多くのレイヤーと機能で構成されており、それに対応して宣言的な管理ルールも非常に複雑です。Kubernetes自体を理解することは重要ですが、DevOpsの受験者は、Kubernetes管理を容易にするために登場した代表的なオープンソースプロジェクトについても習熟しておく必要があります。LPI DevOps Tools Engineer認定では、Helm、Kustomize、Flux CD、Argo CDに関する基本的な知識が求められます。 Helm Kubernetesアプリケーションの管理において最も重要なツールの一つがHelmです。Helmはパッケージマネージャーであり、アプリケーションの定義、インストール、ライフサイクル管理を簡素化します。 Helmのインストールは簡単で、環境や好みに応じて複数の方法があります。Debian系やRed Hat系のLinuxディストリビューションでは、公式のインストールスクリプトを使用するのが最も簡単で、セットアップ全体を自動化できます。 Chartとは何か Helmにおける基本単位はChartです。Chartは、Kubernetesリソースの集合を記述した構造化ファイル群であり、テンプレート、デフォルト設定、メタデータなどを含みます。これにより、アプリケーションを異なる環境でも一貫してデプロイできます。 Releaseは、Kubernetesクラスター内にデプロイされたChartのインスタンスを指します。Chartをインストールするたびに新しいReleaseが作成され、一意の名前が付与されて状態が管理されます。これにより、同一アプリケーションの複数インスタンスを異なる設定で共存させることが可能になります。 Valuesは、Chartをカスタマイズするための設定値で、通常はvalues.yamlというファイルに定義されます。このファイルにはテンプレートに適用されるデフォルト値が含まれています。 ユーザーはインストール時やアップグレード時にこれらの値を上書きできるため、テンプレート自体を変更することなく柔軟な設定が可能です。この「テンプレートと値の分離」はHelmの重要な設計思想であり、再利用性と一貫性を高めます。 Helmを使ったインストール・更新・削除 Helmはアプリケーションのライフサイクル管理をシンプルに行うためのワークフローを提供します。helm installコマンドによりChartをクラスターへデプロイし、新しいReleaseが作成されます。 Helmのセットアップ後は、Chartリポジトリを追加します。利用可能なリポジトリはArtifact Hubで確認できます。リポジトリの追加は以下のように行います。 $ helm repo add bitnami https://charts.bitnami.com/bitnami 追加後、以下のコマンドでChartを検索できます。 $ helm search repo bitnami アプリケーションをデプロイするにはhelm installコマンドを使用します。まずローカルのリポジトリ情報を更新します。 $ helm repo update 次にChartをインストールします。以下の例ではMySQLをインストールしています。 $ helm install bitnami/mysql この処理により、Chartがダウンロードされ、テンプレートが値に基づいてレンダリングされ、新しいReleaseとしてクラスターにデプロイされます。 既存アプリケーションの更新にはhelm upgradeを使用します。このコマンドは差分更新を行い、イメージ更新や設定変更、新機能の有効化などを反映します。また、Helmは各Releaseの履歴を保持しており、必要に応じてロールバックも可能です。 デプロイ済みアプリケーションの確認にはhelm listを使用します。クラスターまたは特定の名前空間内のRelease一覧を確認できます。 不要になったアプリケーションはhelm uninstallで削除できます。関連リソースも含めて削除されるため、不要なオブジェクトが残ることはありません。 values.yamlによるカスタマイズ Helmにおけるカスタマイズは主にvalues.yamlファイルで行います。このファイルにはレプリカ数、イメージバージョン、サービスタイプ、リソース制限などの設定が含まれます。 このファイルを編集する、またはデプロイ時に別の値を指定することで、開発環境・検証環境・本番環境などに応じた設定が可能になります。 コマンドラインオプションや追加のYAMLファイルによる上書きも可能で、ベース設定を維持しつつ環境ごとの差分を適用できます。テンプレートエンジンはこれらの値を動的に処理し、Kubernetesマニフェストへ反映します。 この仕組みによりモジュール性が高まり、同一Chartを複数の環境で再利用できるようになります。 Kustomize Kustomizeは、Helmとは異なるアプローチでKubernetes設定を管理するツールです。テンプレートではなく、既存のYAMLマニフェストに対してレイヤーやパッチを適用することに重点を置いています。 ベース設定を定義し、その上にオーバーレイを重ねて特定の項目のみ変更できるため、元のファイルを変更せずに柔軟な構成管理が可能です。 Kustomizeはkubectlに標準で組み込まれており、追加インストールなしで利用できます。テンプレート言語を導入せず、宣言的な構成管理を維持したいチームに適しています。 Helmがパッケージ化とパラメータ化を重視するのに対し、Kustomizeは構成の合成と変換を重視します。用途に応じて両者を併用することも可能です。 Flux CDとArgo CD Flux CDとArgo CDは、Gitリポジトリを基盤としてKubernetesリソースのデプロイと同期を自動化するGitOpsツールです。HelmやKustomizeの概念を拡張し、継続的デリバリーを実現します。 GitOpsモデルでは、クラスターの望ましい状態をGitリポジトリに保存します。Flux CDとArgo CDはこれを継続的に監視し、実際のクラスター状態を定義通りに保ちます。 これにより、一貫性、追跡性、自動復旧が実現されます。 Argo CDは豊富なUIと詳細な可視化機能を提供し、Flux CDは軽量でKubernetesとの統合が強力です。どちらもHelmやKustomizeに対応しており、柔軟なデプロイ戦略を実現できます。 HelmとGitOpsツールを組み合わせることで、完全に自動化された再現性のあるアプリケーションデリバリーパイプラインを構築できます。 Kubernetesアプリケーション管理と関連ツールへの理解を深めるうえで、LPI DevOps Tools Engineer認定の公式ラーニングマテリアルは非常に有用です。これらは無料で提供されており、Chart、Release、Values、アプリケーションのライフサイクル管理などのトピックを体系的に学習できます。学習内容の整理と理解の定着に役立つでしょう。 << このシリーズの前の記事を読む | 次の記事を読む >>

2026年3月26日、日本・東京 —Linux Professional Institute（LPI）日本支部は、2026年度よりタイ王国の日本型高等専門学校（Thai KOSEN）において、Security EssentialsおよびLinux Essentials International認定に対応したLPIの英語版ラーニングマテリアルが採用されることを発表しました。これらの教材は、ITセキュリティおよびLinuxの基礎を網羅しています。 タイの工科系高等教育機関においてサイバーセキュリティ教育を推進する際、基礎的な技術コンテンツを一から開発し、それを教材として整備することは、教員にとって非常に大きな負担となっていました。さらに、急速に進化するサイバーセキュリティ分野において、内容の最新性と正確性を維持することも大きな課題でした。 こうした背景のもと、世界的に評価され、実績のあるLPIの英語カリキュラムを採用することで、教育者の負担を軽減しつつ、高品質で国際的に通用するIT教育を提供できる環境が整えられました。 学生はこれらの教材をWeb上から直接ダウンロードし、印刷して学習することができます。 Security Essentials：ITセキュリティにおいて、個人および組織が必ず守るべき基本要素を網羅しています。初めてセキュリティを学ぶ学生や、安全にITを活用するための基礎スキルを身につけたい方を対象としています。 Linux Essentials：オープンソースコミュニティの基盤であるLinuxの基礎を体系的に学べる内容となっています。 これらの英語版ラーニングマテリアルは、学生が技術的知識を習得できるよう設計されており、デジタル形式と紙媒体の両方で学習を支援します。 本カリキュラムを通じて、学生はサイバー空間で自らを守る方法を学びます。さらに、LPI認定資格を取得することで、将来の雇用主や顧客に対して、自身の知識とスキルを客観的に証明できるようになります。 タイの高等専門学校の卒業生は、タイ国内にとどまらず、日本企業やグローバルなIT市場においても、即戦力となるセキュリティ人材として活躍することが期待されています。 Linux Professional Institute（LPI）について Linux Professional Institute（LPI）は、オープンソース分野の専門家のスキル向上を支援する世界最大の非営利団体です。180か国以上で試験を実施し、多言語の教育教材を提供することで、IT人材のキャリア開発を支援しています。 メディア連絡先 大野 真Linux Professional Institute 日本支部info-ja@lpi.org

DevOps Tools Engineer 2.0試験の目標703.2では、「Kubernetesの基本操作」が扱われます。この分野は試験の中でも重要な割合を占めており、Kubernetes上でアプリケーションをデプロイおよび管理する方法について、しっかりとした理解が求められます。受験者は、次のことができる必要があります。 宣言的なYAMLファイルを用いてKubernetesリソースを操作できる Podが基本的な実行単位であることを理解している Deploymentを使ってアプリケーションのライフサイクル（スケーリングやローリングアップデートを含む）を管理できる ServiceやIngressを使ってアプリケーションを公開する方法を理解している PersistentVolumeClaimを用いて永続ストレージを提供できる この目標は非常に重要であるため、概念の理解だけでなく、Kubernetesクラスターを使った実践的な演習にも十分な時間を割く必要があります。 YAMLファイルを用いたKubernetesリソースの宣言 Kubernetesのリソースは通常、YAMLファイルを用いた宣言的な方法で定義されます。これらのファイルはシステムの「望ましい状態」を記述し、Kubernetesは実際の状態がその定義と一致するように管理します。この宣言的な構成により、バージョン管理、再現性、自動化といったDevOpsの重要な原則を実現できます。 一般的なKubernetesのYAMLファイルには、以下の要素が含まれます。 apiVersion：Kubernetesコントローラと通信するAPIのバージョン kind：リソースの種類 metadata：名前やラベルなどのリソース情報 spec：望ましい状態の定義 以下はシンプルなPod定義の例です。 apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: web spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 リソースを作成するには、次のコマンドを実行します。 $ kubectl apply -f pod.yaml Podの基本概念 PodはKubernetesにおける最小のデプロイ単位です。1つ以上のコンテナをまとめた単位であり、以下を共有します。 同一のネットワーク名前空間（IPアドレスやポート） 共有ストレージボリューム ライフサイクル管理 Podは本質的に一時的（エフェメラル）な存在であり、通常はDeploymentなどの上位コントローラによって管理されます。 以下は複数コンテナを持つPodの例です。 apiVersion: v1 kind: Pod metadata: name: multi-container-pod spec: containers: - name: app image: myapp:1.0 - name: sidecar image: log-collector:1.0 このYAMLでは、同一環境内で2つのコンテナが動作します。 appコンテナ：メインアプリケーション（myapp:1.0） sidecarコンテナ：ログ収集などの補助機能（log-collector:1.0） 両コンテナはlocalhostで通信可能で、ストレージも共有できます。この構成は「サイドカーパターン」と呼ばれます。 Deploymentの利用方法 DeploymentはPodを管理し、常に指定された数のレプリカが稼働するようにします。主な機能は以下の通りです。 宣言的アップデート 自己修復（Podの再作成） スケーリング ローリングアップデートおよびロールバック 例： apiVersion: apps/v1 kind: Deployment metadata: name: web-deployment spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: [...]

本記事は、現代のデータ収集について扱う連載の一部です。これまでの記事では、さまざまな機関において情報の侵入がいかに広範に行われているかを示してきましたが、今回は多くの人が特に注目する「政府」に焦点を当てます。 このセクションは、1970年代にさかのぼるあるエピソードから始めます。私の友人2人が結婚予定を住んでいた町の役所に届け出ました。これは、結婚を法的に認めてもらうために誰もが行う通常の手続きです。ところがその後すぐ、地元の百貨店から結婚登録（ウェディングレジストリ）を勧める案内が届き始めました。百貨店が彼らの婚約を知る手段は、町の役所以外には考えられません。つまり、地方自治体が住民に提出を義務付けた情報を利用し、それを収益化していたということです。 以前にも触れたように、政府は人権活動家やテロリストといった「敵」を特定するために高度な監視を行います。しかし、この結婚の例が示す通り、政府は日常業務の中で、私たち一人ひとりに関するごく一般的な情報も大量に記録しています。各種登録制度は、私たちが政府に提供しなければならない情報の多さを思い出させます。その一部を挙げると、次のようなものがあります。 世帯構成員（年齢、人種、退役軍人かどうかなどの詳細情報） 学齢児童（健康診断や予防接種の情報など） 土地、住宅、その他の建築物、および大規模な建設工事 税申告書に記載される収入などの情報 性犯罪に関する情報 自動車 銃器 結婚 犬、場合によっては猫 さらに、次のような情報も記録されます。 政府が提供する医療保険に関連する健康情報 投票行動や政治献金を含む政治活動に関する情報 軍歴 カメラによって収集される自動車や歩行者に関する情報 実際のところ、米国政府は多くの納税者について、税額を自動計算できるほどの情報を把握しています。多くの国ではすでにそのような仕組みが存在します。それにもかかわらず、何億人ものアメリカ人が毎年手作業で申告書を作成しなければならないのは、強力な税務申告業界によるロビー活動の影響が大きいとされています。 政府が一般市民や居住者から収集するデータの包括的な一覧については、Privacy.Netの記事やElectronic Privacy Information Center（EPIC）のサイトが参考になります。政府が記録している情報の一部を簡単に挙げると、次の通りです。 基本的な個人情報（氏名、住所、生年月日、社会保障番号など） 生体情報（指紋、顔認識画像、DNA、虹彩スキャンなど） 移民関連情報（渡航履歴、移民申請時に提出された詳細情報） 法執行関連情報（通話記録、交友関係や家族関係、鑑識情報、裏付けのない告発など） 情報機関による情報（秘密裏の活動で得られた情報） こうしたデータが、政府にとって好ましくない人物の特定や訴追に利用される可能性については、多くの懸念が指摘されています。 また、政府が収集した情報の一部は公開されます。米国では、どの政党に投票したかという情報や政治献金は公開情報です。このようなオープンデータは透明性の確保に役立ちますが、地域によっては警察に通報しただけでも、その情報が公開される場合があります。 影響が過大に語られがちなデータ収集の例として、中国の「社会信用システム」があります。確かに、これはさまざまな情報源から住民のデータを一元化する仕組みです。しかし主な用途は企業に対するものであり、食品汚染などの問題を防ぐことが目的とされています。 この社会信用制度については、人材関連企業RemotePadが公開している約1時間のレポート動画を強くおすすめします。同社が香港に拠点を置いているため視点に偏りがある可能性はありますが、制度の実態について非常に詳細に解説されており、信頼できる内容となっています。 本連載の最終回では、雇用主によるデータ収集を取り上げ、現代におけるプライバシーの全体像について総括します。 << 本シリーズの前回記事を読む | 次回記事を読む >>

関数型プログラミングは、プログラミング言語を分類するうえでの基本的な区分のひとつであり、その起源はプログラミングの初期にまでさかのぼります。特にLISPやMLが代表的です。本シリーズでは、現代の関数型言語の主要な提唱者へのインタビューを通じて、その重要性や影響を探ります。 私たちの多くは、命令型言語でプログラミングを学びました。そこでは、レシピのように1つの文が次の文へと順番に実行されます。ループは繰り返し処理を行い、if文は分岐を可能にします。また、あらかじめ定義された処理を再利用するために、文は関数やサブルーチンとしてまとめられます。 命令型や関数型に加えて、プログラミング言語のもうひとつの大きな分類が宣言型プログラミングです。その代表例がPrologです。宣言型プログラミングでは、プログラマや管理者がシステムの「望ましい状態」を定義し、プログラムがその状態を実現します。この手法は、Ansibleのような現代のシステム管理ツールで広く使われており、多くの場合YAMLファイルが用いられます。 現在でも比較的新しいとされる関数型言語には、以下のようなものがあります。 Erlang（1980年代後半に開発） Haskell（1980年代後半〜1990年代初頭に開発） OCaml（1996年に公開） F#（2002年、Microsoftによる参入） Scala（2004年に公開） これらの言語は話題になることは多かったものの、大規模な普及には至りませんでした。私が勤務していたO'Reilly Mediaでも、これらの言語に関する書籍を出版していました。本シリーズでは、その当時O'Reillyと関わりのあった著者たちにインタビューを行っています。本シリーズでは、これらの言語がどのように使われているのか、関数型プログラミングがコンピュータサイエンス全体にどのような貢献をしてきたのか、そしてその間にプロのプログラミングがどのように変化してきたのかを見ていきます。 本シリーズでは、関数型プログラミングの革新的な特徴を2つのカテゴリーに分けています。ひとつは主に構文的で学びやすい特徴で、これらは命令型言語にも取り入れられてきました。もうひとつは本質的な特徴であり、関数型プログラミングを関数型たらしめている要素です。この後者は、命令型プログラミングとは概念的に大きく隔たっています。 こうした歴史を踏まえ、インタビューした専門家の中には、自分たちの言語（ひいては関数型言語全般）を「プログラミングの実験場」と捉える人もいます。新しいアイデアを発見し、それを外の世界へ提供する場というわけです。O'Reillyの書籍『Erlang Programming』や『Designing for Scalability with Erlang/OTP』の著者であるFrancesco Cesariniは、すべてのコンピュータサイエンス教育課程で関数型プログラミングが教えられるべきだと考えています。 関数型プログラミングの背景 「関数型プログラミング」という用語はどこから来たのでしょうか。あるAI検索では「1960年代の研究の一環としてPeter Landinがこの用語を作った」とされていますが、その出典は確認できませんでした。別の検索では「この用語の発明者として特定の人物はいない」とされています。 ここで関数型プログラミングの厳密な定義を行うつもりはありませんし、「純粋関数型かどうか」といった不毛な議論に立ち入るつもりもありません。 本質的には、関数型プログラミングの理念は「副作用を持たないこと」です。他の言語では、関数内で変数の値を変更したり、関数外にグローバル変数を定義したりできます。一方、関数型プログラミングでは、関数は値を返すこと以外に影響を持ちません。Haskellコンパイラ（Glasgow Haskell Compiler）の開発に長年携わってきたSimon Peyton Jonesは、次のように説明しています。 「関数型プログラミング（数学と同様）では、変数は値を表します。一方、命令型プログラミングでは、変数は変更可能な記憶領域を指し、その値は時間とともに変化します。」 実用面では、関数型モデルは2つの重要な概念を導入します。それは「不変（イミュータブル）な変数」と「非同期通信」です。変数が変更されないと分かっていれば、コンパイラはより効率的に処理をスケジュールできます。また、非同期通信はロックやバリアを不要にし、並行処理を容易にします。 これに対して命令型言語は、変更可能な変数に依存しています。関数は変数を書き換えることで状態を表現し、それが関数間のコミュニケーション手段となります。 （ストレージなどにおける不変性の広範な活用については、ACM Queueの古典的な記事が参考になります。） もちろん、関数型プログラムも最終的には結果を出力したり、外部に影響を与えたりする必要があるため、「副作用なし」という原則を完全には守れません。ファイルへの書き込みやネットワーク送信などは不可避です。しかし、特にHaskellのIOシステムやErlangのI/Oプロトコルでは、副作用を伴う処理とそうでない処理を厳密に分離します。ほとんどの関数は純粋であり、外部に影響を与えません。関数型言語は、The Whoの『Tommy』に登場する「目も耳も口も不自由だがピンボールは得意な少年」にたとえられるかもしれません。 ダンス会場の壁の花 過去数十年にわたる関数型言語の人気については、十分な情報が得にくいのが現状です。TIOBEインデックスは長期的な統計を公開していますが、対象はわずか10言語で、本記事で扱う言語は含まれていません。Redmonkのランキングでも、過去14年間で言及されているのはScalaのみです。 現在の人気については、ZDNETの2024年ランキングやIEEE Spectrum、Statistaの2025年調査などで確認できますが、本シリーズで扱う言語はいずれも上位には登場しません。 比較のために見ると、Visual Basic、Fortran、Adaといった一部では時代遅れと見なされる言語の方が上位にランクインしています。これは、既存の利用基盤が大きいことが理由でしょう。 しかし、人気は言語の価値を測る適切な指標ではありません。JavaScriptやTypeScriptはWebページ表示のために設計されているため人気がありますが、ニッチな用途で高い価値を持つ言語も存在します。 Scala Scalaは、本シリーズで取り上げる言語の中では比較的多くの利用者を獲得しました。これは、ScalaがJava仮想マシン（JVM）上で動作するバイトコードにコンパイルされるためです。同様の言語としてKotlin、Clojure、Groovyなどがあります。Javaと同じ環境で動作するため、長年蓄積されたJavaライブラリを活用できる点が大きな利点です。 ただし、関係者によればScalaの人気はピークを過ぎているとされています。Redmonkランキングでは一定の地位を維持していますが、勢いは落ちています。 『Programming Scala』の著者であるDean Wamplerは、Scalaを「研究的な言語」と位置づけています（Haskellも同様です）。そのため、改善のために後方互換性が犠牲になることもありますが、これは大規模に普及した言語では避けられる傾向があります。 Scalaは当初、Javaの冗長さに不満を持つ開発者に支持されました。「Javaが停滞していた時期に、Scalaでは1行で書けるクラスがJavaでは20行必要だった」とWamplerは述べています。その簡潔さは衝撃的でした。しかし、Java 8でラムダ式などの関数型機能が導入されたことで、Scalaの優位性は相対的に低下しました。 現在では、Scalaは「言語好きのための言語」となっています。特にAI分野では豊富なライブラリが利用できるため、強力な言語よりもPythonのようなシンプルな接着言語で十分だと指摘されています。 Haskell Peyton JonesもHaskellを「実験場」と見なしており、必要に応じて後方互換性を犠牲にすることを認めています。コミュニティが密接である限り、柔軟な進化が可能です。ただし、普及が進むにつれて互換性への配慮も強まっています。 Haskellは革新の源泉としての役割を今後も担い続けると期待されています。たとえば、Peyton Jonesが開発したトランザクショナルメモリは、複数操作の原子性を保証するだけでなく、ミューテックスなしでスレッド同士の待機を可能にします。この機能は非常に有用で、Microsoftが.NETへの導入を試みたものの、命令型言語では実現が困難だったといいます。 また、Haskellには一般化代数的データ型（GADT）といった高度な機能もあり、これは強力な型システムに支えられています。 Erlang Cesariniは、関数型言語がそれほど普及しない理由として、その有用なアイデアが他の言語に取り込まれている点を挙げています。 現在、多くの開発者がErlang仮想マシン上で動作するElixirを利用しています。Elixirの周辺では活発な開発が行われており、WebフレームワークのPhoenixは「21世紀のRuby on Rails」とも呼ばれています。また、AI向けのNumerical Elixirや、組み込み向けのNervesプロジェクトも注目されています。 本シリーズの第2回（最終回）では、命令型言語がどのように関数型の概念を取り入れてきたか、ただしその本質までは取り入れていない点について見ていきます。また、プログラミングの未来についての考察も提示します。

これまでのDevOpsツールに関する解説では、コンテナ仮想化と、それによってアプリケーションのパッケージ化やデプロイ方法がどのように変革されたかを見てきました。コンテナの大きな利点のひとつは、従来の仮想マシンと比較してリソースのオーバーヘッドが非常に小さいにもかかわらず、起動が非常に高速である点です。コンテナはホストOSのカーネルを共有するため、数秒で起動でき、同一のインフラ上で多くの分離されたワークロードを効率よく実行できます。 しかし、コンテナによってアプリケーションのパッケージ化や実行は簡素化された一方で、複数のサーバーにまたがる大量のコンテナを管理することは急速に複雑になります。現代のアプリケーションは、数十、場合によっては数百のコンテナで構成され、それらをスケジューリングし、監視し、障害時には再起動し、需要に応じて動的にスケールさせる必要があります。これらの作業を手動で行うことは、本番環境では現実的ではありません。 この課題を解決するために登場したのが、コンテナオーケストレーションプラットフォームです。これらは、複数のマシンからなるクラスター上で、コンテナのデプロイ、スケーリング、ネットワーク管理、ライフサイクル管理を自動化することを目的としています。その中でも、Kubernetesはコンテナ化されたワークロードのオーケストレーションにおいて、最も広く採用されているソリューションとなっています。 KubernetesはもともとGoogleによって開発され、その後Cloud Native Computing Foundationに寄贈されました。分散されたコンテナアプリケーションを信頼性高く大規模に管理できる、強力かつ拡張性の高いアーキテクチャを提供しています。 Pods, Services, Deployments,controllersといった概念を導入することで、管理者やDevOpsエンジニアはインフラの「望ましい状態（Desired State）」を定義でき、プラットフォーム側がその状態を維持するよう継続的に制御します。 本章では、Kubernetesのアーキテクチャ、クラスターの主要コンポーネント、そしてkubectlなどのツールを使ってクラスターの状態を確認し、リソースを管理する方法について解説します。 Kubernetesクラスターのアーキテクチャ Kubernetesクラスターは、2つの主要な要素から構成される分散システムです。 コントロールプレーンはクラスターを管理しスケジューリングを行い、ワーカーノードはアプリケーションのワークロードを実行します。 このアーキテクチャにより、Kubernetesはアプリケーションの望ましい状態を維持できます。管理者はサーバー上で手動でプロセスを起動する代わりに、意図する構成を宣言するだけで、Kubernetesがその状態に一致するようクラスターを自動的に調整します。 コントロールプレーンの主要コンポーネント コントロールプレーンには、クラスター管理とオーケストレーションを担う重要なコンポーネントが含まれます。 API Server Kubernetes API Server（kube-apiserver）は、クラスターの中心となる通信ハブです。管理者がkubectlや内部コンポーネント、各種自動化ツールを通じて行うすべての操作は、このAPIを経由します。 主な役割は以下の通りです。 Kubernetes REST APIの公開 リクエストの認証および認可 リソース定義の検証 クラスター状態のetcdへの保存 クラスターへの入口となるため、ステートレスなサービスとして設計されており、水平スケーリングが可能です。 etcd etcdは、Kubernetesの永続ストレージとして使用される分散型キーバリューデータベースです。設定情報、ノード情報、リソース定義など、クラスターに関するすべての情報を保存します。 Pod、Deployment、Serviceなど、すべてのKubernetesオブジェクトはetcdに記録されます。そのため、etcdはクラスターの「唯一の信頼できる情報源（Single Source of Truth）」となります。 etcdが利用できなくなると、すでに動作中のワークロードは継続する可能性がありますが、新規作成や更新などの変更は行えなくなります。 Controller Manager Controller Manager（kube-controller-manager）は、複数のコントローラーを実行し、クラスターの状態を継続的に監視して、望ましい構成を維持します。 コントローラーは「リコンシリエーションループ」を実装しており、実際の状態と望ましい状態を繰り返し比較し、差異があれば修正を行います。 主なコントローラーの例： Node Controller ReplicaSet Controller Deployment Controller Service Controller これにより、ワークロードの可用性と一貫性が保たれます。 Scheduler Kubernetes Scheduler（kube-scheduler）は、新しく作成されたPodをクラスター内のどのノードで実行するかを決定します。リソースの空き状況や制約、ポリシーを考慮して最適なノードを選択します。 主な判断基準： CPUやメモリの空き状況 ノードアフィニティルール テイントとトレラント ワークロードのバランス ワーカーノードの構成要素 ワーカーノードはアプリケーションのワークロードを実行し、通常は以下のコンポーネントを含みます。 kubelet：コントロールプレーンと通信するノードエージェント コンテナランタイム：containerdやDockerなど kube-proxy：ネットワークおよびサービスルーティングを担当 これらにより、Podの実行と状態報告が可能になります。 kubectlの設定 kubectlは、Kubernetesクラスターと通信するためのコマンドラインツールです。APIサーバーと連携し、リソースの管理やクラスター状態の取得を行います。 設定は通常、~/.kube/config ファイルに保存され、以下の情報を含みます。 クラスターのエンドポイント 認証情報 コンテキスト ネームスペース 設定の管理には kubectl config コマンドを使用します。 kubectl get リソース情報の取得は、Kubernetes操作の中でも最も基本的な作業です。 例： $ kubectl get pods $ kubectl get [...]

金曜の夕方。あなたがオフィスを出ようとしたそのとき、あの嫌な電話が鳴ります。「本番サーバーが応答しません。確認できますか？」 社内VPNに接続しますが、2分おきに切断されてしまいます。3時間後も、実際の問題解決ではなくネットワーク設定と格闘している状態です。 こうした日常的なストレスが、何千人もの開発者やシステム管理者に代替手段を探させてきました。そこで登場するのがNetBirdです（図1）。 [caption id="attachment_36861" align="aligncenter" width="1920"] 図1：接続済みピア、分かりやすい名前、接続状態を表示するNetBirdのダッシュボード[/caption] 実際に機能するネットワーク NetBirdは、見た目だけを改良した単なるVPNではありません。トラフィックを中央のボトルネックに通すのではなく、デバイス同士が直接通信するメッシュネットワークを構築します。 仕組みは、エージェントをインストールした瞬間から動き出します。手動設定や.ovpnファイル、ポートフォワーディングは不要です。新しいデバイスは、自動的に許可されたすべてのピアからアクセス可能になります。 設定ゼロで最大のセキュリティ 自宅ラボを考えてみてください。監視用のRaspberry Pi、バックアップ用のNAS、あるいはJellyfinサーバーなどがあるかもしれません。通常であればポート開放やDDNS設定、IPアドレス変更への対応が必要です。 しかしNetBirdなら、その複雑さは消えます。すべてのデバイスに分かりやすい名前と固定IPアドレスが割り当てられます。 Grafanaのダッシュボードを確認したい場合も、もはやssh -L 3000:192.168.1.15:3000のようなコマンドは不要です。ブラウザで grafana.superkali.lan を開くだけでアクセスできます（図2）。NetBirdのプライベートDNSにより、まるで常に自宅ネットワーク内にいるかのように利用できます。 [caption id="attachment_36871" align="aligncenter" width="1920"] 図2：ブラウザでgrafana.superkali.lanにアクセスし、Grafanaが表示されている様子[/caption] 分散チームのためのツール リモートチームでの作業にも最適です。例えば、あなたのノートPC上のPostgreSQLデータベースを、ベルリンのデザイナーのMacBookやAWS上のステージングサーバーから簡単に利用できます。 セットアップキーを使えばオンボーディングも瞬時です。新しい開発者にはキーを渡すだけ。エージェントをインストールすれば、数秒で内部サービスにアクセス可能になります。チュートリアルもサポートも不要、「自分の環境では動くのに…」といった問題も減少します。 インテリジェントなP2P接続 従来のVPNがすべての通信を中央サーバー経由で処理するのに対し、NetBirdはWebRTC技術を使ってデバイス同士を直接接続します。これはビデオ通話にも使われている技術です。NATやファイアウォールを自動的に突破し、ピアツーピア接続を確立します（図3）。 [caption id="attachment_36881" align="aligncenter" width="1920"] 図3：NetBirdによる直接のピアツーピア接続[/caption] ただし、モバイルネットワークや厳しい企業ファイアウォールなどでは直接接続が失敗する場合もあります。その場合はリレーサーバーにフォールバックしつつ、WireGuardによるエンドツーエンド暗号化を維持します。リレーは暗号化されたデータを中継するだけで、中身を読むことはできません。 内部では、WireGuard（暗号化）、Pion ICE（WebRTC）、Coturn（NAT越え）、Rosenpass（耐量子暗号）などが使われています。また、Google Workspace、Okta、ZitadelなどとのSSOやMFAにも対応しています。 オープンソースと柔軟な料金体系 NetBirdはオープンソース（BSD-3-Clause/AGPLv3）です。セルフホストなら完全無料で制限もありません。クラウド版は5ユーザー・100デバイスまで無料、それ以上は1ユーザーあたり月額5ドルです。 細かなアクセス制御 アクセス管理はIPアドレスではなく、論理グループで行います。例えば「開発者はステージングにはアクセス可能だが本番には不可」といった設定も、グループとポリシーで簡単に実現できます（図4）。 [caption id="attachment_36891" align="aligncenter" width="1920"] 図4：グループ管理インターフェース[/caption] この制御はネットワークレベルで適用され、アプリごとの設定は不要です。NetBirdはアイデンティティと権限を理解するスマートファイアウォールを備えています。 オープンに開発されるプロジェクト NetBirdは、エンタープライズ向けネットワークの複雑さに不満を持ったエンジニア、Misha Bragin氏とMaycon Santos氏によって生まれました。 「誰でも設定の専門家にならずに安全なネットワークを使えるべき」という理念のもと開発されています。 GitHubでは1万以上のスターを獲得し、コミュニティも活発です。耐量子暗号の対応などはユーザーの要望から追加されました。オープンソースであるため、特定ベンダーに縛られることもありません。 実際のパフォーマンス 性能は重要です。従来のVPNで10GBのバックアップをNASに転送した場合は18MB/sでしたが、NetBirdの直接接続では95MB/sに達しました。中央ゲートウェイではなく、実際の回線速度がボトルネックになります。 通常の環境では、80〜90%の接続が直接P2Pで確立されます。つまり、ほとんどの通信は最大速度でやり取りされます。 ネットワークの未来 NetBirdは、「セキュアなネットワークは自然に動くべき」という未来を体現しています。iptablesの知識は不要で、デバイスの追加も数秒で完了します。 3か月前まではVPN設定の維持に週末を費やしていましたが、今ではプロジェクト開発に時間を使えています。優れたインフラとは、意識せずに使えるものです。 分散チーム、自宅ラボ、企業インフラのいずれにおいても、NetBirdは「本来存在すべきでない問題」を解消します。VPNがボトルネックであってはなりません。 試してみませんか？セルフホスト版のNetBirdは完全無料のオープンソースで、セットアップはこの記事を読むより短時間で完了します。