こんにちは。クロスイノベーション本部の平岡です。 弊社のAzureクラウドSOC（以下Azure SOC）では、Azure環境のセキュリティ設定の可視化と改善、およびセキュリティインシデントの早期発見と調査支援を行っています。 私はAzure SOC運営メンバーとして主にMicrosoft Defender for Cloudを活用し、Azure環境のセキュリティ設定の監視を行っています。 前回書いた ブログ では、Azure SOCで活躍している便利なサービスの一部として、Microsoft Defender for CloudのCSPM機能とCWP機能の概要を紹介しました。 今回はCWP機能の一つであるセキュリティアラートを、メールもしくはMicrosoft Teams（以下Teams）の任意のチャネルに自動通知する方法についてご紹介したいと思います。 セキュリティアラートをメールで通知したい場合 Microsoft Defender for CloudのCWP（クラウドワークロード保護）を有効にすることで、セキュリティアラート画面上に、クラウド環境内で脅威が検知されるようになります。詳細は 前回ブログ をご一読ください。 セキュリティアラートはMicrosoft Defender for Cloudの通知設定もしくは、Azure Monitorのアラート設定を行うことで、メールで通知できます。 特にMicrosoft Defender for Cloudの通知設定は非常に簡単に設定できるため、CWPを活用している場合は設定することをお勧めします。 Microsoft Defender for Cloudのメール通知設定 メールの受信者にはAzure RBACの一部ロールを設定するか、直接メールアドレスを設定できます。 例えば「所有者」ロール選択時には、「所有者」権限が割り当てられている全員宛にMicrosoft Defender for Cloudからメールを受け取ることができます。 Azure Monitorのアラート設定 Azure Monitorのアラート設定では、より詳細に条件を設定できます。 セキュリティアラートをTeamsの任意のチャネルに通知したい場合 単一サブスクリプションを管理している場合はメール通知で十分だと思いますが、Azure SOCではAzure Lighthouseを利用し、弊社内の複数プロジェクトのサブスクリプションのセキュリティ情報を集約しています。 そのため、セキュリティアラート発出時には、サブスクリプション管理者に即時で対応してもらうために、個々のサブスクリプション連絡用チャネルに即時でTeamsの通知を飛ばしたいと考えました。 やりたいこと Microsoft Defender for Cloudのセキュリティアラート発出をトリガーとして、Logic Appsを起動する Excelファイル内のテーブル情報を取得する セキュリティアラートに紐づくサブスクリプションIDと、Excelファイル内のサブスクリプションIDを突き合わせて、該当のTeamsのグループIDとチャネルIDを取得する 取得したグループIDとチャネルIDに該当するTeamsのチャネルに通知する Microsoft Defender for Cloudでワークフローの自動化設定を行う セキュリティアラートが想定のチャネルに投稿されることを確認する 1~4はAzure Logic Apps（以下Logic Apps）で設定し、5はMicrosoft Defender for Cloudで設定します。 最後にサンプルアラートを出して、想定したチャネルに投稿されることを確認します。 Logic Appsの設定 Logic AppsはAzure上で提供されるクラウドベースのワークフローの自動化サービスです。 さまざまなアプリやサービスをつなぎ、業務プロセスを自動化できます。 特徴 ローコード/ノーコードで構築可能 トリガーとアクションの組み合わせで定義 多種多様のコネクタが利用可能(Teams、Microsoft Defender for Cloud、Microsoft 365、Salesforce、X(Twitter)等) 1~4のやりたいことをトリガーとアクションを組み合わせて定義します。 1. Microsoft Defender for Cloudのセキュリティアラート発出をトリガーとして、Logic Appsを起動する メニューの[ロジックアプリデザイナー]を選択すると、[トリガーの追加]ボタンが表示されます。検索欄に"Defender for Cloud"と入力すると、セキュリティアラート以外にもレコメンデーション（推奨事項）や規制コンプライアンスの発出がトリガーとなるコネクタがあることがわかります。 今回は、「Microsoft Defender for Cloud の警告が作成またはトリガーされた場合」トリガーを選びます。 2. Excelファイル内のテーブル情報を取得する トリガーを作成するとアクションを追加できるようになります。 [アクションの追加]ボタンを押下し、検索欄に"Excel"と入力すると、さまざまな種類のExcelコネクタが表示されます。 今回は、「表内に存在する行を一覧表示」アクションを選びます。 Teams内に格納しているExcelファイルにアクセスして、テーブルの情報を取得します。 ExcelファイルにはサブスクリプションID、Teamsのチャネル名、TeamsのグループID、TeamsのチャネルIDを記載しています。Excel内のデータ範囲は、あらかじめテーブルとして書式設定しておく必要があります。 3. セキュリティアラートに紐づくサブスクリプションIDと、Excelファイル内のサブスクリプションIDを突き合わせて、該当のTeamsのグループIDとチャネルIDを取得する [アクションの追加]ボタンを押下し、検索欄に"Filter array"と入力すると、紫のアイコンのビルトインアクションが表示されます。 （ビルトインアクションはタイトルの右横に青字で"Built-in"と表示されています） パラメータタブで、[FROM]にExcelファイルの"Value"を選択します。 [Filter Query]の左辺には動的なコンテンツからExcelファイル内のサブスクリプションID、右辺にはセキュリティアラートに紐づくサブスクリプションIDを選択して、一致する情報をExcelファイルから取得するように設定します。 4. 取得したグループIDとチャネルIDに該当するTeamsのチャネルに通知する [アクションの追加]ボタンを押下し、検索欄に"Teams"と入力し、"チャットまたはチャネルでメッセージを投稿する"チャネルを選択します。 パラメータタブで、[投稿者]は"フローボット"や"ユーザ"を選択できます。プライベートチャネルに投稿したい場合は"ユーザ"を選択しないとエラーになります。 [投稿先]は"グループチャット"または"チャネル"が選択できます。 [チーム]はExcelファイル内の"group_id"、[チャネル]はExcelファイルの"channel_id"を選択します。※"group_id"を選択することで、自動的にループ処理が追加されます。 [メッセージ]では提供したい情報を記載したり、特定の相手にメンションすることもできます。 For each処理のパラメータには"Filter array"の"Body"を選択します。 以上でLogic Appsの設定は完了です。 5. Microsoft Defender for Cloudでワークフローの自動化設定を行う Microsoft Defender for Cloudでワークフローの自動化設定を行います。 メニューで[ワークフローの自動化]を選択し、[＋ワークフロー自動化の追加]を押下します。 [ワークフローの自動化の編集]画面が表示されるため、トリガーの条件やLogic Appsを選択して保存します。 6. セキュリティアラートが想定のチャネルに投稿されることを確認する 最後にセキュリティアラートが想定のチャネルに投稿されることを確認します。 実際にセキュリティアラートを出すのはリスクがあるため、今回はMicrosoft Defender for Cloudの標準機能であるサンプルアラートを出してテストします。 サブスクリプションBのサンプルアラートを出してみます。 サブスクリプションBチャネルを確認すると、無事通知が投稿されていました。 まとめ 今回はMicrosoft Defender for Cloudのセキュリティアラートを、メールまたはTeamsのチャネルに投稿する方法をまとめました。 ローコード/ノーコードで利用できるLogic Appsで、他にも便利な自動化ツールを作成できそうです。 みなさんも是非Logic AppsとMicrosoft Defender for Cloudを組み合わせて活用してみてください！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @hiraoka.eri2 レビュー： @ozaki.hisanori （ Shodo で執筆されました ）

はじめに こんにちは、コーポレートエンジニアリング部ITサービスブロックの高塩です。2026年2月に入社し、社内の共通システムやIdP、SaaSの管理、日々のオペレーション自動化などを担当しています。 ZOZOでは入社者のマスタデータをkintoneで管理しています。入社のたびに、Active Directory（以下、AD）を起点にMicrosoft 365・Google Workspace・Boxなどでアカウントを作成し、利用できる状態まで整えています。この作業は長らく手作業で運用してきましたが、工数や属人化、そしてCSVの受け渡しに課題を抱えていました。 オンプレADやLDAPサーバーを長く運用してきた組織では、それが自動化の足枷になっているケースも少なくないと思います。かといって、すべてをクラウドへすぐに寄せられるとも限りません。本記事では、この一連のアカウント作成を、kintoneを起点にGitHub Actions（self-hosted runner）で自動化した取り組みを紹介します。閉域にあるオンプレADの操作までGitHub Actionsに載せ、コードレビュー・実行ログ・再現性といったCI/CDの利点をアカウント運用に持ち込みました。 目次 はじめに 目次 背景：手作業時代のフローと課題 全体アーキテクチャ オンプレADをGitHub Actionsから操作する kintoneから翌月の入社予定者を取得し、業務ロジックで判定してADに作成する 同期待ちを能動的に潰して即時反映する AD → Entra ID：デルタ同期を要求して完了までポーリング Entra ID → SaaS：Graph APIのオンデマンドプロビジョニング 運用：前日にdry-runで予定を流し、翌日に本番で作成する 導入の効果 まとめ 背景：手作業時代のフローと課題 自動化前のアカウント作成は、おおよそ次のような流れでした。 GASでkintoneから入社者のレコードを取得する スプレッドシートに転記し、関数で表示名やグループなどの値を加工する 加工した結果をCSVでエクスポートし、オンプレミスの作業サーバーへ手動で転送する 作業サーバー上で複数のPowerShellスクリプトにCSVを読み込ませ、順次実行してアカウントを作成する 途中、Microsoft Entra Connectのデルタ同期を手動で実行し、各SaaSへの反映を待つ 反映後、各SaaSの個別設定を、設定用スクリプトの実行や手作業で投入する 一見すると回っているように見えますが、運用を続けるうちに次のような課題が積み重なっていました。 業務ロジックが散在している ：誰が・どの雇用形態で・どのグループに入るのか、その判断ロジックがスプレッドシートの関数と作業サーバー上のスクリプトに分散していました。そのため全体像の把握が困難でした。 手作業でのCSV転送 ：スプレッドシートからCSVをエクスポートし、作業サーバーへ人手で転送していました。 ログの視認性が低い ：実行は作業サーバーのコンソールで行うため、いつ・誰が・何を流したのかが後から追いにくい状態でした。 スクリプトのドリフト ：Gitリポジトリ上のスクリプトと、作業サーバーに置かれた実際に動くスクリプトが少しずつ乖離していき、「リポジトリのコード＝実際に動いているコード」と言い切れなくなっていました。 これらをまとめて解決するために、フロー全体を作り直すことにしました。 全体アーキテクチャ 新しい仕組みでは、データはkintoneから直接取り、全工程をGitHub Actionsから動かすことにしました。 手作業のころから大きく変えたのは、次の3つです。 CSVの受け渡しをやめ、kintone APIを直接呼び出す ：人の手によるエクスポートと加工を排除しました。 散在していた業務ロジックをコードに集約する ：判断ロジックをすべてPowerShellスクリプトにまとめ、Gitリポジトリで管理するようにしました。 オンプレADの操作にself-hosted runnerを使う ：GitHub Actionsの仕組みに乗りながら、オンプレミスのADコマンドレットをそのまま実行できるようにしました。 ワークフローは schedule によるcron実行で動きます。kintoneからはデフォルトで翌月の入社者を取得するので、毎月決まった日に翌月分の作成予定をSlackへ自動投稿し、その翌日にまとめて作成する、という運用にしました。 ここからは、土台となるself-hosted runner、kintoneからのアカウント作成、クラウドへの即時反映を、順に見ていきます。 オンプレADをGitHub Actionsから操作する この仕組みで一番頭を悩ませたのが、オンプレミスのADをどう自動化に組み込むかでした。 ADはオンプレミスの閉じたネットワークの中にあります。操作するには、次の3つが必要です。 ドメインコントローラへ通信できるネットワーク（オンプレ内）にいること リモート サーバー管理ツール（ RSAT ）の ActiveDirectory モジュールが入った実行環境 対象OUでユーザー作成とグループ追加ができるドメイン権限 最初に検討したのは、この処理を自前でオーケストレーションせず、Entra ID Governanceのようなマネージド機能に寄せる形でした。たとえばオンプレADへのユーザー作成は、 API 駆動型インバウンド プロビジョニング に任せられます。 ただ、今回の要件には合いませんでした。アカウント作成にはオンプレADのグループ操作が含まれますが、属性ベースの動的グループが扱うのはクラウドのグループで、オンプレADのグループメンバーシップまでは管理しません。ここはマネージド機能だけでは実現できません。 さらに、出し分けの業務ロジックは、手作業時代のPowerShellスクリプトへある程度作り込まれていました。これを一から組み直すより、既存の資産をそのまま流用したい事情もありました。そこで今回は、自前でオーケストレーションする方針にしました。 自前で組むなら、ADを操作する方法はいくつかあります。検討した選択肢の長所と短所を、次の表にまとめました。 実行方式 長所 短所・見送り理由 タスクスケジューラ＋スクリプト 追加インフラが不要 時刻起動のみ・コードがサーバーに残りドリフト再発・ログやSecrets、レビューが弱い 自前でAPIを建てる オンデマンド実行・自由度が高い 着信ポートの開放が必要・認証や可用性、監視を自前運用 Azure Automation（Hybrid Runbook Worker） Power Automate/Microsoft Formsから起動しやすい・Azure/M365中心の組織に馴染む GitのPR/CIと一体化しにくい・別基盤の学習/運用コスト self-hosted runner（採用） 既存のGitHub・PR・CIにそのまま乗る・チェックアウトでドリフトなし・手動/定期の両対応 runnerの保守が必要・信頼できるコードのみ実行する配慮が要る 自前API以外の3方式は、オンプレからのアウトバウンド通信だけで動作し、外部に着信ポートを開ける必要がありません。 最終的に self-hosted runner を選びました。ADドメインに参加したWindows Server上でrunnerを動かし、PowerShellを実行しています。 コード・トリガー・ログがすべてGitHub側へ移り、サーバー上では実行時にチェックアウトされた最新のスクリプトが動くだけです。背景で挙げたドリフトは、これで自然に消えます。 ほぼ同じ仕組みは、AzureのHybrid Runbook Workerでも実現できます。私たちはGitHubを使った業務フローが根付いていたため、self-hosted runnerを選びました。 ただし、この構成では強い権限を持つrunner自体が攻撃対象になります。runnerを侵害させないことと、万一侵害されても被害を広げないことの両方に注意を払う必要があります。 runnerに任意のコードを実行させる入口はGitHubなので、次のような基本的な制御を入れています。 リポジトリをprivateにし、権限は必要なメンバーだけに限定する ログインはSSOを必須とし、MFAの登録を義務づける mainはbranch protection ruleでCODEOWNERのレビュー承認を必須にする 認証は原則OIDC（Workload Identity連携）を使い、やむを得ずシークレットを使う場合もEnvironmentシークレットに置いてmainのワークフローからのみ参照できるようにする self-hosted runnerのサービスを動かすアカウントに過剰な権限を与えないことも重要です。runnerはオンプレADからクラウドまで触れる強い実行主体なので、万一侵害されたときの影響範囲を抑えるため、アクセスできるOUを絞るなど、必要最低限の権限だけを与えています。 kintoneから翌月の入社予定者を取得し、業務ロジックで判定してADに作成する 土台ができたら、次はアカウントを作る処理です。 まず取得です。kintoneの Cursor API を使い、クエリで対象者を絞り込みます。条件は3つで、入社月・入社区分（中途や新卒など）・雇用形態（社員やアルバイトなど）です。対象月は、定期実行では NEXT_MONTH() で翌月分を自動的に対象にします。 # 入社区分・雇用形態・入社月で対象者を絞り込む $categoryFilter = 'Category in ("中途", "新卒", "社員登用", ...)' $contractFilter = 'Contract in ("社員", "出向", "CSアルバイト", ...)' $query = " $categoryFilter and $contractFilter and Date = NEXT_MONTH() order by Date desc" # カーソルを作成し、レコードを取得し切るまで繰り返す $cursorId = ( Invoke-RestMethod -Uri $cursorEndpoint -Method Post -Headers $headers -Body $utf8Body ).id $nextCursorId = $cursorId while ( $nextCursorId ) { $res = Invoke-RestMethod -Uri " $cursorEndpoint `? id= $nextCursorId " -Method Get -Headers $getHeaders $allRecords += $res .records $nextCursorId = $res .next } CSVのエクスポートと手動転送がなくなり、「どんな条件で対象者を抽出しているか」がクエリを見れば分かるようになりました。 ただ、取得したデータをそのままADに流し込めるわけではありません。雇用形態や所属によって、どのOUに作り、どのグループに入れるかが変わります。以前はこの出し分けがスプレッドシートの関数に埋もれていましたが、今回コード側の分岐に移しました。判定しているのは、たとえば次のような内容です。 雇用形態に応じた、アカウントの配置先OUの決定 所属に応じた、各種グループへの追加 その他のユーザーアカウント属性の設定 判定が終わったら、self-hosted runnerの上で ActiveDirectory モジュールのコマンドレットを実行し、ADにアカウントを作成します。あとは次に述べる同期で、クラウド側へ反映されていきます。 同期待ちを能動的に潰して即時反映する ADにユーザーを作っただけでは、クラウド側のアカウントはすぐには使えません。間に2つの同期が挟まるためです。 1つ目はAD → Entra IDです。オンプレADのユーザーは、Microsoft Entra Connectが同期して初めてEntra ID側に現れます。この同期は通常、30分間隔のサイクルでしか走りません。 2つ目はEntra ID → 各SaaSです。Entra IDからGoogle WorkspaceやBoxへは、エンタープライズアプリのプロビジョニングで連携されます。この自動プロビジョニングのサイクルは最大40分待つことがあります。 手作業のころは、この待ちを人がこなしていました。同期サイクルが回るのを待つか、待ちきれなければデルタ同期を手動で叩き、クラウドにアカウントが現れたのを確認してから次の設定に進む、という具合です。 ところが、これをそのまま自動化に持ち込むと厄介でした。AD作成の先には、Entra IDのライセンスやグループ設定、Google WorkspaceやBoxへのプロビジョニング、その後の各SaaS個別の設定が続きます。どれも前の結果を前提にした処理です。定期サイクル任せだと全部終わるまでに1時間近くかかるうえ、まだ存在しないアカウントを触って空振りするステップも出てきます。 そこで、2つの同期をワークフローから自分でトリガーし、完了を見届けてから次へ進むようにしました。 AD → Entra ID：デルタ同期を要求して完了までポーリング 1つ目の同期は、Microsoft Entra Connectの同期サーバーに対してデルタ同期を要求し、完了するまで待ちます。runnerから Invoke-Command で同期サーバーに入り、 Start-ADSyncSyncCycle でデルタ同期を開始したあと、同期が進行中でなくなるまでポーリングします。 Invoke-Command -ComputerName $syncServer -ScriptBlock { Import-Module ADSync Start-ADSyncSyncCycle -PolicyType Delta | Out-Null # 同期が完了するまで待つ do { Start-Sleep -Seconds 10 $inProgress = ( Get-ADSyncScheduler ).SyncCycleInProgress } while ( $inProgress ) } ポーリングで完了を待つので、後続の処理に進む時点では、新入社員が必ずEntra ID側に存在します。 この Invoke-Command によるPowerShell Remotingは、runnerが侵害されたときに同期サーバーへの横移動の足がかりになりかねません。そこで、同期サーバーへ接続できる元をrunnerに限定し、接続に使うアカウントの権限も同期の実行に必要な分だけに絞っています。 Entra ID → SaaS：Graph APIのオンデマンドプロビジョニング 2つ目の同期は、Entra IDの自動プロビジョニングのサイクルを待たず、Graph APIの provisionOnDemand を使ってユーザー単位で即座にプロビジョニングをトリガーします。 このリクエストには、対象アプリのサービスプリンシパルID（ $spId ）・同期ジョブID（ $jobId ）・同期ルールID（ $ruleId ）の3つが必要です。ただ、こちらで用意するのは1つ目だけです。 $spId はエンタープライズアプリの「オブジェクトID」で、Entra管理センターのアプリのプロパティ画面に表示されます。 残りの $jobId と $ruleId は、実行時に $spId からGraphで取得します。ユーザーの同期ルールはアプリごとに1つしかないので、同期ジョブのスキーマを覗けば、それがそのまま使うルールです。IDを手で管理する必要はありません。 # $spId から同期ジョブを取得（Quarantine以外を優先） $jobs = Invoke-MgGraphRequest -Method GET ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs" $jobId = ( $jobs .value | Where-Object { $_ .status.code -ne "Quarantine" } | Select-Object -First 1 ).id # ジョブのスキーマから、ユーザーが対象の同期ルールを選ぶ $schema = Invoke-MgGraphRequest -Method GET ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs/ $jobId /schema" $ruleId = ( $schema .synchronizationRules | Where-Object { $_ .objectMappings.sourceObjectName -contains "User" } | Select-Object -First 1 ).id あとは、取得した $jobId と $ruleId 、そしてプロビジョニング対象のユーザーを指定してリクエストを投げます。 $body = @{ parameters = @( @{ ruleId = $ruleId subjects = @(@{ objectId = $userObjectId ; objectTypeName = "User" }) } ) } Invoke-MgGraphRequest -Method POST ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs/ $jobId /provisionOnDemand" ` -Body ( $body | ConvertTo-Json -Depth 10 ) ` -ContentType "application/json" この2つで同期待ちを潰すと、AD作成・各SaaSへのプロビジョニング・その後のSaaSごとの設定までが一本につながります。プロビジョニングのサイクルを待たずに済むので、後続の設定も同じ実行の中で流し込めます。終わった時点で、結果がSlackとジョブログに残ります。 運用：前日にdry-runで予定を流し、翌日に本番で作成する 毎月の作成は、dry-runと本番の2段階で回しています。 前日に走るのはdry-runです。AD作成やプロビジョニングといった変更は実際には行わず、「何をするか」（翌月入社者の作成予定）をSlackに流します。チームはこの通知で対象者を確認できるので、kintoneのデータに不備があっても、本番の前に気づけます。 翌日に本番が走ります。処理の開始から各ステップ、完了までを1本のSlackスレッドに流し、完了サマリーと、失敗したときのエラーだけはチャンネルにもブロードキャストして気づけるようにしています。作業サーバーのコンソールを覗かなくても、SlackとGitHub Actionsのログだけで実行状況を追えます。手作業時代に困っていた「ログの視認性の低さ」は、これで解消しました。 もう1つ効いているのが冪等性です。アカウント作成は既存ユーザーをスキップし、グループ追加も「すでにメンバー」を無視します。途中のステップが失敗しても、直して同じワークフローを流し直せば、できているところはそのまま、足りないところだけが埋まります。 また、プロビジョニングの後に各SaaSで行う個別の設定は、SaaS側の状態によっては失敗することがあります。これらは失敗しても全体を止めず、結果をSlackに残して先へ進む設定にしています。気づいたら、その部分だけ後で流し直せば済みます。 導入の効果 一番大きいのは、毎月の新入社員アカウント作成がほぼ無人で回るようになったことです。これまで人がCSVを受け渡し、スクリプトを手で実行し、同期を待っていた一連の作業が、1回のワークフロー実行にまとまりました。 業務ロジックもコードに集まり、「どの条件で何が付与されるか」をリポジトリで追えます。リポジトリのコードと実際に動くコードが一致するので、ドリフトも起きません。 まとめ 本記事では、新入社員のアカウント作成を、kintoneを起点にGitHub Actionsで自動化した取り組みを紹介しました。オンプレADの操作はself-hosted runnerで担い、散らばっていた業務ロジックはコードにまとめ、同期待ちはGraph APIのオンデマンドプロビジョニングで潰しました。手作業で属人化していた運用を、コード化して実行を追える形にできました。 オンプレミスとクラウドが混在する環境でアカウント運用を自動化したい方の参考になれば幸いです。今後は、退職時のアカウント無効化など、入社から退職までのライフサイクル全体へ自動化を広げていく予定です。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

  Linux初心者がAzure仮想マシンでHTTPサーバーを構築した話 --> こんにちは！新卒でサイオステクノロジーに入社したごままぐろです。 本記事では、Linux初心者が研修で得た学びを以下の構成でご紹介します。LinuxはITパスポートなどの資格勉強で少し知っている程度だったのですが、この度新卒研修の一環としてLinux仮想環境でのサーバ構築を行いました。 これからLinuxを学ぶ方の参考になれば幸いです。 Linuxについて Linuxとは LinuxはWindowsやMacのようなOS（Operating System）の一種です。OSS（Open Source Software）として公開されているため、世界中の開発者が自由にプログラムの中身を確認したりカスタマイズできます。 厳密にいえば、「Linux」とはOSの核心である「カーネル」のことを指すようです。しかし実際には、カーネルに独自の管理ツールやアプリケーションを組み合わせた「Linuxディストリビューション」のことをLinuxと呼ぶことが多いそうです。 有名なLinuxディストリビューションには以下のものがあります。 RedHat系： RHEL、AlmaLinux など Debian系： Debian、Ubuntu など Linuxの特徴 Linuxには以下のような特徴があります。 基本的に文字ベースで操作する データをディレクトリとファイルの入れ子構造で管理する ユーザごとに権限を設定できる 私の場合、このあたりの特徴を掴むのに時間がかかりました。今も完全に理解できているか分からないのですが、私なりの言葉で簡単に説明したいと思います。 LPI-Japanという団体が初学者向けに 「Linux標準教科書」 という資料を公開しているので、正確な情報を知りたい方はそちらを参照してみてください。 １．基本的に文字ベースで操作する Linuxでは、キーボードで命令（コマンド）を入力するCUI（Character User Interface）での操作が基本です。 Linuxのコマンドは基本的に「コマンド」「オプション」「引数」で構成されます。 同じ操作でも、ディストリビューションによっては別のコマンドやオプションが存在する場合があるため、注意が必要です。 ２．データをディレクトリとファイルの入れ子構造で管理する Linuxでは、データはディレクトリとファイルの入れ子構造で管理されます。 ディレクトリはフォルダのようなもので、ファイルを整理するための入れ物です。ディレクトリの中にさらにディレクトリを作ることもでき、これを入れ子構造と呼びます。 ファイルを操作する時には、ファイルの住所（パス）を指定する必要があります。パスには、最上位（/ルートディレクトリ）からの絶対パスと、現在のディレクトリからの相対パスがあります。 絶対パス： /home/username/newdir/file1.txt 相対パス：(現在の位置が/home/usernameの場合) newdir/file1.txt ３．ユーザごとに権限を設定できる Linuxには「ユーザ」という概念があります。ユーザには、人がログインして操作を行うためのものの他に、人がログインできず内部でプログラムを動かすためのものもあります。 Linuxでは、ユーザごとに権限を設定できます。権限には、読み取り（r）、書き込み（w）、実行（x）の3種類があります。 例えば、ファイルに何か書き込みたいと思っても、自身が操作するユーザにその権限がなければ書き込むことはできません。 権限を設定するコマンドもあるため、必要に応じて割り当てたり変更する必要があります。 本章の内容は以上です。 次章では、実際にLinux仮想環境を用意してサーバ構築を行った手順をご紹介します。 Linux仮想環境でのサーバ構築 仮想マシン(AzureVM)の用意 Linuxは、コンピュータ（ハードウェア）の機能を管理しプロセスとの仲立ちを行うカーネルと、カーネルに人間の出した命令（コマンド）を翻訳し伝えるシェルで構成されています。 実際にLinuxを動かして学ぶには、コマンドを出す対象となるコンピュータが必要です。 しかし私が現在使っているコンピュータはWindowsという別のシステムが管理しているため、Linuxのコマンドを書いても通じません。 そのため今回は仮想化されたコンピュータである「Azure VM（Virtual Machines）」というクラウドサービスを利用して仮想環境を構築しました。 仮想マシンOSには、「Red Hat Enterprise Linux (RHEL) 9.4」を選択しました。 Windows環境を維持したままLinuxを実際に操作する方法は他にもいろいろあるので、ご自身のパソコンやその他条件に応じて選択することをおすすめします。 仮想マシンにSSH接続 仮想マシンを作成したら、次はそれに接続する必要があります。 今回はSSHという通信プロトコルを使って接続しました。 SSHは暗号化された通信を行うためのプロトコルで、今回のようにコンピュータが手元にない（リモート）場合でも安全に接続することができます。 SSH接続の手順は以下の通りです。 仮想マシン作成時に生成された秘密鍵を自分のパソコンに保存する ターミナル（コマンドプロンプト）を開き、以下のコマンドを実行して接続する ssh -i 秘密鍵のパス ユーザー名@IPアドレス 初回接続時には、ホストキーの確認が求められるので「yes」と入力 HTTP通信に必要なもののインストールと設定 作成した仮想マシンには最低限の機能しかないため、目的に応じて必要な部品や設定を追加する必要があります。 今回は、Webブラウザにアドレスを入力するとWebページが表示されるようにしたかったので、Apacheというものをインストールしました。 １．Azure Portalで受信ポート規則の変更 認証のため受信ポート22番（SSH）を許可する ソースは安全のため自分のIPアドレスに限定する ２．仮想マシン上でApacheのインストール sudo dnf install httpd ３．Apacheの起動と自動起動設定 ・サービスの起動 sudo systemctl start httpd ・自動起動の有効化 sudo systemctl enable httpd ４．RHELの内部ファイアウォールでHTTPトラフィックの許可 ・HTTPの許可 sudo firewall-cmd --add-service=http --permanent ・設定の反映 sudo firewall-cmd --reload ５．Azure Portalで受信ポート規則の変更 Webページを閲覧するため受信ポート80番（HTTP）を許可する ソースは自分のIPアドレスに限定する 表示するコンテンツの作成 Apacheのデフォルト設定では、「/var/www/html」ディレクトリにHTMLファイルを置くことで、Webページとして表示されるコンテンツを作成できます。 今回は、以下のコマンドで「index.html」を作成しました。 sudo vi /var/www/html/index.html Linuxでファイルを編集するには、viエディタなどのテキストエディタを使用します。 viエディタには実際に中身を編集するインサートモードと、ファイルの保存や終了などの操作を行うコマンドモードがあります。 慣れないうちは操作が難しく、何度かパニックになりました。   Webページの表示確認 Webブラウザに仮想マシンのIPアドレスを入力すると、作成したWebページが表示されます。 Azure Portalの受信ポート規則でソースを自分のIPアドレスに限定しているため、他のIPアドレスからはアクセスできません。 感想とまとめ 以上が今回のサーバ構築で行った内容でした。全くの初心者の私にとっては非常に充実した経験となりました。 実はこの後も様々な学習を続けており、現在は認証認可というもっと高度な設定に挑戦しています。余裕があれば現在取り組んでいる内容もまとめたいと思っているため、また機会があればよろしくお願いします。 長くつたない文章を最後までお読みいただき、ありがとうございました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post Linux初心者がAzure仮想マシンでHTTPサーバを構築した話 first appeared on SIOS Tech Lab .