おはようございます！ zenncast、MCのマイクです。10月25日、日曜日、朝7時になりました。日曜日の朝、皆さんいかがお過ごしでしょうか。今日もZennでトレンドになっている記事から、気になる話題をお届けします。
今日は、コードの難読化、SELinuxのアクセス制御、Rust向けの解析ライブラリ、証明書の更新、そしてAIによる脆弱性診断という、5本の記事をご紹介します。
....
まず1本目は、Pythonのコードを難読化するPyarmorについてのお話です。
難読化というのは、プログラムの動作は変えずに、コードを読みにくくする技術です。ここで大切なのは、コードを完全に隠す技術ではなく、解析にかかる手間を増やすものとして考えることなんですね。
記事では、Pyarmorの標準設定だと、関数名や文字列を簡単に取り出せることが紹介されています。AIを使った実験でも、元のコードの大部分が復元されたそうです。難読化したから安心、とは言い切れないわけですね。
そこで、保護を強めるための機能を組み合わせます。文字列を暗号化するmix-str、名前を変更するRFT、関数を機械語に変換するBCC、そして外部からの参照を制限するprivateです。こうした機能を重ねることで、解析を難しくできます。
ただ、強い設定を使っても、単純な処理なら入力と出力の関係から推測されることがあります。記事の実験では、複雑な処理はほとんど復元できなかったとのことですが、これは安全を保証する結果ではありません。
また、保護を強めることには代償もあります。ライブラリが動かなくなったり、処理速度が落ちたりする可能性があるんです。外部との窓口になる部分と、守りたい重要な処理とで設定を分け、納品前にきちんと動作確認をすることが大切です。
技術だけでなく、解析や流用を禁じる契約も重要です。そして、絶対に知られてはいけない値は、そもそも納品するコードに入れない。この線引きは、しっかり覚えておきたいですね。
....
続いて2本目は、SELinuxで不要なアクセスを減らすお話です。
SELinuxは、rootで動くプログラムに対してもアクセス制限をかけられる仕組みです。記事では、Rootless Dockerのデータを例に、どんなルールでアクセスが許可されているのかを調べていきます。
まず確認するのが、Typeという分類ラベルです。ファイルやディレクトリに付いたTypeと、プロセスに付いたTypeをそれぞれ調べます。Typeは、アクセス制御の判断に使われるものなんですね。
記事では、独自のTypeとしてcompose_data_tを作り、semanageのfcontextとrestoreconを使って、/var/compose以下に適用しています。標準のvar_tを使う場合よりも、アクセスを許可する対象を絞れるようにするわけです。
さらに、sesearchで許可ルールを調べ、seinfoで、そのTypeがどのAttributeに属しているかを確認します。Attributeは複数のTypeをまとめるグループのようなもので、1つのTypeが複数のグループに属することもできます。
ここで注意したいのが、Dockerのcontainer_runtime_tです。このTypeは、広い範囲のファイルアクセスを許すグループに属しています。そのため、ファイル側を独自のTypeに変更しただけでは、Dockerからのアクセスは遮断されません。
ラベルを変えたら終わりではなく、グループへの所属や、そこから適用される許可ルールまで見る必要があるんですね。アクセス制御の仕組みを一段深く理解できる内容です。
....
3本目は、Rust向けのライブラリ、prprをご紹介します。
prprは、文法のルールから、文字列を解析するプログラムを生成するライブラリです。PEGという文法の書き方を使い、読み書きのしやすさと、高速な解析の両立を目指しています。
使いやすさに関わる機能として、空白の読み飛ばしや、単語の区切りを自動で扱ってくれます。また、解析に失敗したときは、どの位置で失敗したのか、そこにはどんな文字などが必要だったのかを表示できます。文法を作ったり直したりするときに、こうした手がかりがあるのは助かりますよね。
速度に関わる工夫もあります。解析結果を保存して再利用する仕組みは、必要なルールだけに指定できます。さらに、処理が遅くなりそうな箇所を、事前に調べる機能も備えています。
文法はRustのコードに直接書けますし、追加ライブラリなしで動くコードとして出力することもできます。記事に掲載されているJSONとGraphQLの比較では、既存の複数のライブラリより高速な結果が示されています。
もちろん、この比較で示された条件での結果として見る必要はありますが、文法の扱いやすさと実行速度、その両方を重視したい方には気になるライブラリですね。
....
続いて4本目は、証明書の更新について、見落としやすいポイントを扱った記事です。
取り上げられているのは、eMudhraの中間CAの秘密鍵漏洩です。中間CAというのは、サイトの証明書を発行する認証局のこと。この記事の大切なメッセージは、OSを更新しただけでは対策が終わらない、という点です。
なぜかというと、アプリやコンテナが独自に持っている証明書一覧は、古いまま残ることがあるからなんですね。
確認には、公開されているテスト用ホストへの接続を使います。curlだけでなく、Pythonの環境や、それぞれのコンテナからも接続を確認します。証明書エラーとして拒否されず、内容が返ってきた場合は、更新が必要です。
Pythonでは、仮想環境ごとのcertifiに加えて、pip本体も確認して更新します。Node.jsやuv、コンテナのイメージなどについても、それぞれ対応が必要になります。1か所更新したから全部大丈夫、とはいかないところですね。
また、Electronアプリなどは更新したあとに再起動します。そして、「更新成功」と表示されたことだけで安心せず、実際に動いているファイルの版を確認すること。さらに、偽の証明書をきちんと拒否するところまで確かめることが重要です。
更新したという記録だけでなく、動いている環境で対策が効いているかを見る。運用で大切にしたい確認ですね。
....
最後、5本目は、AI脆弱性診断ツール、Shannonを使った検証のお話です。
Shannonは、ソースコードと、動作中のWebアプリを調べるツールです。記事の筆者は13件の指摘候補を得て、そのうち、権限チェックが不足している問題と、入力内容がログに丸ごと残る問題の2件を再現しました。
導入の過程では、OpenAIのセキュリティ用途のアクセス確認で、作業が止まる場面もあったそうです。その後、YubiKeyの登録と本人確認を経て、Daybreak Blueを取得しています。対応するモデルでは、防御目的の依頼が拒否されにくくなりますが、扱いはモデルごとに異なるという点には注意が必要です。
診断では、最初から攻撃実証まで実行するのではなく、まずその機能を無効にして、分析だけを実行しています。そして、出てきた指摘は、確定した問題とは限りません。個別に実際の挙動を確かめることが大切です。
もう1つ、診断前の準備として強調されているのが、壊しても元に戻せる環境を用意することです。本番環境から隔離し、初期化できるデータベース、テスト用のアカウント、操作に必要なデータをそろえておくと、安全に確認を進めやすくなります。
AIが出した候補を、人が検証する。その検証自体も、安全にやり直せる場所で行う。ツールの力を生かすための土台が、よく伝わってくる記事ですね。
....
さて、今日のzenncastは、5本の記事をお届けしました。
Pyarmorによる難読化は、完全に隠すのではなく解析の手間を増やすもの。SELinuxのアクセス制御は、TypeだけでなくAttributeや許可ルールまで確認すること。Rust向けのprprでは、文法の扱いやすさと高速な解析の工夫をご紹介しました。
そして、証明書の対策はOSだけでなくアプリやコンテナまで確認すること。Shannonによる脆弱性診断では、指摘を個別に検証し、元に戻せる環境を用意することがポイントでした。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてくださいね。番組の感想もお待ちしています。「この話が参考になった」といった一言も、うれしいです。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです。
それでは、次回も皆さんにお会いできるのを楽しみにしています。素敵な日曜日をお過ごしください。お相手は、マイクでした！