2025/05/24
概要と背景 かつて先進的な取り組みであったIaCやCI/CDも昨今はさほど珍しいものではなくなりました。その有益性が実感されていればこそでしょう。DORAのサイトにおいても 、“Infrastructure-as-code allows you to manage changes effectively, and to apply information security controls. “と述べられるように、効果的かつセキュアな運用にIaCやCI/CDは大きく貢献します。
しかし具体的にどのようなメリットがあるのかを改めて説明しようとすると意外と難しいものです。そこでこの機にまとめなおしてみました。
DevOpsにつきもののCI/CD、そのメリットとは?
なぜIaCとCI/CDを用いるのか。得るべきそのメリットとは。 IaCとCI/CDのメリットをそれぞれ整理したのが以下の表です。
IaC(Infrastructure as Code)のメリット 区分 具体的な利点 説明 再現性 同じコードから何度でも同一環境を構築可能 設定漏れや設定ミスの発生を抑止し、環境差異の極めて少ない環境構築が可能になります。 可読性・共有性 インフラを設定で可視化できる 必然的に設定が明文化されるため、知識が属人化しにくくなります。 バージョン管理 Gitでバージョン管理できる インフラをGitで管理できます。変更を追いかけるロールバックも容易です。 モジュール化による再利用 共通コードで省力化 何度も利用する設定をモジュール化して使いまわせば効率よく構築できます。設定ミスがおきづらいことから信頼性も高いです。 ツールの利用 静的解析でチェックできる checkovなどでコードレベルでインフラの構成をチェックできます。
実はIaC(インフラのコード化)単体ではメリットを出しづらく、多くはほかの施策や技術と組み合わせることで効果を発揮します。
例えば、再現性や可読性、モジュール化による再利用はそれを可能にするコードを書いてこそ機能します。バージョン管理はGitを導入・運用していなければなりません。静的解析のツールも同様です。
IaCの導入とは、ただTerraform(あるいはCDKやCloudFormation等)を用いるだけではなく、その他のツールや技術も合わせた総合的な施策なのだと言えます。
CI/CDのメリット 区分 具体的な利点 説明 自動化による信頼性向上 plan -> (approve) -> apply を自動で実行できる 作業ミスやメンバーごとの手順の違いなどを抑止します。運用の信頼性を向上させます。 テスト・チェックの確実な実行 静的解析やterraform planなどを自動実行できる チェック忘れがなくなります。手動で行っているとフォーマッタやテストツールの実行を忘れるのも日常茶飯事です。 ガバナンス強化 レビューと承認フローを必須にできる terraform planの結果とApprove機能のことです。Githubの機能と組み合わせるとさらに強力です。雑な仕事、悪意ある(!)作業を抑止できます 証跡保存 コード変更・CI 実行ログが残る ログがチーム共用の場に残るため追跡が容易になります。 アクセス権の保護 権限をクラウド上で集中管理できる 普段はCI/CDで更新するようにしておけばメンバーが普段から強すぎる権限を持たずに済みます。ただしブレイクグラスや、そこまでシビアでないならAssumeRoleなど、臨時作業の手段も用意しておく必要があります。
CI/CDの売りはなんといっても信頼性の向上です。昔から業界には作業漏れや作業ミスの笑い話(?)が絶えません。しかし自動化した部分については――自動化でミスしていれば別ですが――そのような問題を抑止することができます。逐一手順書をかかずに済むなど、本番作業の省力化に繋がることもあるでしょう。またミスのリカバリ作業が減ることからコストメリットも副次的に生じるかもしれません。
DevOps
2025/05/24
AI連携エディタは開発作業を効率化できる便利なツールですが、機密情報をうっかり渡してしまわないよう注意する必要があります。AI連携エディタが利用したデータは外部のAIサービスへ送信されているためです。「AI連携機能を利用する」=「外部に情報を送信する」なのです。
機密性の低い情報に対してまで必要以上に警戒すべきとは言えません。それによって効率性を損なうことは別の問題を生じます。また現実問題として外部送信程度なら許容できるケースも多くあることでしょう。しかしAPIキーや顧客の個人情報などの機密性が極めて高い情報については話が別です。このような情報は送信してしまうだけで問題、まして悪用されたとなれば大問題です。ちゃんと外部AIに学習させない設定を有効化していれば外部AIに送った情報は流用されないはずですが、完璧とは限りません。AI連携エディタのCursorの開発元自身、シビアな用途で利用する際は注意するよう呼びかけています。
While we have several large organizations already trusting Cursor, please note that we are still in the journey of growing our product and improving our security posture. If you’re working in a highly sensitive environment, you should be careful when using Cursor (or any other AI tool). (ref: https://www.cursor.com/ja/security )
エディタ内からAIに問い合わせなければ大丈夫とも言いきれません。AI連携エディタはバックグラウンドでもAIを利用しており、気付かないうちに情報が送信されうるためです。むしろ機密情報の書かれた設定ファイルを開くだけでもリスキーと考えるべきです。つまるところ、極めて厳しいセキュリティが必要とされる情報を取り扱っているなら、それらにアクセス自体できないようAI連携エディタを物理的あるいは論理的にシャットアウトするのが一番です。
AIは便利だが機密情報まで送信すべきでない
専用ユーザーを作ろう Windows11の場合、AI連携エディタを利用して開発を行うための専用ユーザーを作成することで、外部に送信される可能性のある情報をしっかり管理できます。この専用ユーザーにはあらかじめ公開可能なプロジェクトのみを渡し、機密情報が保存されたディレクトリにアクセスできないようにしておきます。うっかりミスで機密情報をAI連携エディタに渡してしまう事態を
Powershellで実施する場合はこのようなコードになります。
# AI連携エディタ用ユーザーの作成
#
# [Usage]
# 1. 管理者権限で PowerShell を開きます。
# 2. スクリプトを一時的に実行できるようにします。(e.g. `Set-ExecutionPolicy RemoteSigned -Scope Process`)
# 3. スクリプトを保存したディレクトリに移動し、実行します。 (e.g. `.\create-ai-user.ps1 -Username AIUser -Password pass_is_here`)
param (
[Parameter(Mandatory = $true)]
[string ]$Username,
[Parameter(Mandatory = $true)]
[string ]$Password
)
$SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force
New-LocalUser -Name $Username -Password $SecurePassword -FullName " $Username" -Description "AI editor user (developer)"
if (-not $Username) {
Write-Error "Fail to create user: $Username"
exit 1
}
Add-LocalGroupMember -Group "Users" -Member $Username
管理者ユーザーではなくローカルユーザーとして作成します。その上で機密情報を取り扱うディレクトリやファイルのアクセス権を拒否し、アクセス自体不可能にします。
開発環境