はじめに こんにちは、BASE DepartmentでPHPerをしている @meihei です。 長く運用しているサービスでは、機能の追加や変更を重ねるうちに、「もう使っていなさそうなデータ」が残ることがあります。以前は必要だった配列のキーが残り、その値を取得して受け渡す処理も動き続けている（ただし描画では使っていない）、といった具合です。 使われているデータは残し、不要なものだけを安全に削除したい。そのためには、まず本当に使われていないのかを確かめる必要があります。 この記事では、 ArrayAccess と trigger_error() を使い、廃止候補のキーが読まれたら警告を出す仕組みを紹介します。 背景 パフォーマンス改善のため、無駄な処理をなくしたい APMで分析していたところ、カテゴリ情報に含める商品数を専用のAPIリクエストで取得していることが分かりました。この商品数がテンプレート側で使われていなければ、取得処理を削除し、API通信にかかる時間を削減できると考えました。 ショップごとに異なるテンプレートがある BASEでは、ショップの世界観に合わせてデザインを選び、カスタマイズできます。無料・有料のさまざまなテンプレートに加えて、HTML編集によるカスタマイズも提供しています。 thebase.com そのため、PHPから渡したデータを受け取る側には、数多くのカスタムテンプレートがあります。例えば同じカテゴリ情報を渡していても、カテゴリ名だけを表示するテンプレートもあれば、カテゴリに属する商品数まで表示するテンプレートもあり得ます。 PHP側のコードを見ればデータを渡していることは確認できても、各ショップのテンプレートで実際に参照されているかまでは分からない、という課題がありました。 誤って削除しても表示崩れに気づきにくい ただし、実際には表示に必要だった場合、削除するとテンプレートの表示が壊れます。Twigのデフォルト設定（ strict_variables が false ）では、存在しないキーの値をそのまま表示しようとしてもエラーにならず、その部分が空になります。こうしたバグは気づきにくく、原因の特定や修正も大変です。 カテゴリ情報の受け渡しをTwigで書くと、次のようになります。 echo $twig- > render('category.twig', [ 'category' = > [ 'id' = > 12, 'name' = > 'トップス', 'count' = > $this- > getCountCategory(id: 12), // 数百ミリ秒かかるので消したい処理 ], ]); <h2>{{ category.name }}</h2> <span>{{ category.count }}件</span> このテンプレートが使われているなら、 count はまだ削除できません。 配列からDTOへ移行したい また、データの受け渡しも、配列からDTO（Data Transfer Object）へ移行したいと考えていました。最終的には、必要な項目とその型を明示した、POPO（Plain Old PHP Object）なDTOでデータを渡す形を目指しています。 Twigの category.name という書き方は、配列のキーだけでなく、オブジェクトのpublicプロパティにも使えます。そのため、この参照方法を保ったまま、PHP側で渡す値を配列からDTOへ置き換えられます。 twig.symfony.com ただし、今の配列をそのままDTOにすると、不要な項目まで引き継いでしまいます。そこで、まずは既存の読み方を保ちながら廃止候補のキーの利用状況を確認し、安全に削除できることを目指しました。 配列アクセスを観測しながらDTOへ移行する ArrayAccessで読み取り専用のDTOを作る まずは、配列として読める、読み取り専用のDTOを用意します。PHPの ArrayAccess を実装すると、オブジェクトに対する $dto['name'] のようなアクセスをメソッドで受け取れます。 以下のコードはPHP 8.2以降を対象にしています。最初に読み取りと書き込み禁止を実装し、その後で警告処理を追加します。 abstract readonly class AbstractDeprecatedKeyProbe implements \ ArrayAccess { public function __construct (private array $values) { } final public function offsetExists(mixed $offset): bool { return isset ($this- > values[$offset]); } final public function offsetGet(mixed $offset): mixed { return $this- > values[$offset] ?? null; } final public function offsetSet(mixed $offset, mixed $value): void { throw new \ LogicException (static::class . ' は書き換えられない'); } final public function offsetUnset(mixed $offset): void { throw new \ LogicException (static::class . ' は削除できない'); } } readonlyにする必要がなければ、 ArrayObject を使うのもよいと思います。配列として扱うための実装が用意されているので、そのまま利用できます。今回はDTOをreadonlyにし、配列アクセス経由の書き込みも明示的に禁止したかったため、 ArrayAccess を直接実装しています。 次に、この基底クラスを継承してカテゴリのDTOを作ります。readonlyクラスを継承する子クラスもreadonlyにします。 final readonly class CategoryDto extends AbstractDeprecatedKeyProbe { public function __construct ( public int $id, public string $name, public int $count, ) { parent:: __construct ([ 'id' = > $id, 'name' = > $name, 'count' = > $count, ]); } } コンストラクタでは、通常のDTOと同じように、項目ごとに型を指定して受け取ります。引数をpublicプロパティとして宣言しているので、 $dto->name と読めます。そのうえで、同じ値を parent::__construct() に配列として渡し、既存の $dto['name'] という読み方にも対応させています。 $dto = new CategoryDto( id: 12, name: 'トップス', count: 34, ); echo $dto- > name; // トップス echo $dto['name']; // トップス Twigへ渡す場合は、 category の値をこのDTOに置き換えます。 echo $twig- > render('category.twig', [ 'category' = > new CategoryDto( id: 12, name: 'トップス', count: $this- > getCountCategory(id: 12), ), ]); Twig側の category.name という書き方はそのままです。利用状況を調べる段階なので、 count を取得するAPIリクエストもまだ残しています。 廃止候補のキーへのアクセスを検知する 続いて、安全にキーを削除するために、廃止候補のキーが読まれたら警告を出すようにします。対象のキーはDTOごとに異なるので、基底クラスに次の抽象メソッドを追加します。 abstract protected function deprecatedKeys(): array; CategoryDto では、このメソッドを実装して廃止候補を列挙します。 protected function deprecatedKeys(): array { return ['count']; } 次に、基底クラスの offsetGet() と offsetExists() を変更し、共通の警告処理を呼びます。 final public function offsetExists(mixed $offset): bool { $this- > warnIfDeprecated($offset); return isset ($this- > values[$offset]); } final public function offsetGet(mixed $offset): mixed { $this- > warnIfDeprecated($offset); return $this- > values[$offset] ?? null; } これらのメソッドを final にしているのは、子クラスで上書きした際に警告処理が抜け落ちるのを防ぐためです。廃止候補は各DTOで宣言し、観測方法は共通に保ちます。 基底クラスに追加する warnIfDeprecated() は、次のようになります。 private function warnIfDeprecated(mixed $offset): void { static $warnedKeys = []; static $deprecatedKeyMaps = []; $deprecatedKeys = $deprecatedKeyMaps[static::class] ??= \array_fill_keys($this- > deprecatedKeys(), true); if (! isset ($deprecatedKeys[$offset])) { return; } $warnedKey = static::class . '::' . $offset; if ( isset ($warnedKeys[$warnedKey])) { return; } $warnedKeys[$warnedKey] = true; \ trigger_error ( \sprintf( '%s: 廃止検討中のキー "%s" が参照された。まだ利用者がいるため削除できない。', static::class, $offset, ), E_USER_WARNING, ); } E_USER_WARNING は、PHPのコードから発生させる非致命的な警告です。標準の動作では処理を停止しないので、警告を出した後も元の値を返せます。 trigger_error() でこの警告を出し、既存のエラーハンドラを通じて外部の監視ツールへ送ることで、「このキーにはまだ利用者がいるので、削除を保留する必要がある」と判断する材料にします。 *1 ただし、警告を例外に変換するエラーハンドラでは処理が止まります。導入時には、表示を維持できることと、警告が監視ツールへ届くことを確認します。 カテゴリ一覧をループすると、同じキーへのアクセスが何度も発生します。知りたいのは利用の有無なので、警告は「クラス名とキー名」の組み合わせごとに一度だけにしています。 抑制状態はインスタンス間で共有し、通常はリクエストごとにリセットされます（常駐ワーカーでは持続）。廃止候補の一覧もクラスごとにキャッシュするため、 deprecatedKeys() は同じクラスのどのインスタンスでも同じ配列を返すようにします。 readonlyクラスではstaticプロパティを宣言できないため、警告済みの情報はメソッド内のstatic変数に保持します。これにより、DTOのデータを変更せずに、呼び出しをまたいで警告の重複を抑制できます。 なお、フレームワークなどが用意するヘルパー関数で配列を扱っている場合は、置き換える際に確認が必要です。引数が array 型ならDTOは渡せませんし、内部で配列へキャストする場合は、このアクセスの観測を通りません。 Twigはpublicプロパティより先に ArrayAccess 経由で値を読むため、このDTOの category.count も offsetExists() と offsetGet() を通ります。これで、テンプレートの category.count が参照されたら警告が出るようになります。 *2 廃止できると分かったら、普通のDTOへ戻す 必要な利用経路を確認し、 count を廃止できると判断したら、プロパティと対応する配列キー、その値を取得するAPIリクエストを削除します。コンストラクタの呼び出しからも count の引数を外します。 PHPの $dto['name'] やTwigの category['name'] が残っている場合は、PHPの $dto->name やTwigの category.name に変更します。読み方を揃えたら、 AbstractDeprecatedKeyProbe の継承と parent::__construct() も外せます。最後に残るのは、次のような普通のDTOです。 final readonly class CategoryDto { public function __construct ( public int $id, public string $name, ) { } } Twigへは引き続き category として渡せるので、 {{ category.name }} はそのまま使えます。観測のために用意したDTOを捨てる必要はなく、必要な項目だけを持つPOPOなDTOとして使い続けられます。 おわりに 今回は、 ArrayAccess と trigger_error() を使い、既存の動作を保ちながら廃止候補のキーへのアクセスを観測する方法を紹介しました。 観測の仕組みを外したあとには、必要な項目だけを持つPOPOなDTOが残ります。不要な処理を減らせて、データの受け渡しも型付きのDTOに移行できる。この両方を進められるのが、今回の仕組みのうれしいところです。 突然ですが私は、デッドコードを削除したり、無駄な処理を消してパフォーマンスを改善したりするのが大好物です。AIによってコードをどんどん増やせるようになった今だからこそ、安全にコードを消せる仕組みを用意して、積極的に不要なコードを消していくことが大事だと思っています！ こうした日々の改善を通じて、サービスを支えるコードを一緒に育てていきたい方は、ぜひ採用情報もご覧ください！ binc.jp *1 : この方法は、 NewRelicと戦うレガシーPHP を参考にしました。 *2 : この実装では、Drupalの DeprecatedArray も参考にしました。ArrayObjectを継承し、アクセス時にE_USER_DEPRECATEDを出しながら元の処理を続ける、近い発想の実装です。Drupalでは配列全体を非推奨として扱いますが、今回は廃止候補のキーに絞って観測しています。

こんにちは、NTTドコモビジネス情報セキュリティ部です。 NTTドコモビジネスを含めたドコモグループでは今年も現場受け入れ型インターンシップを開催いたしました。 情報セキュリティ部でも5つのポストに対して8人のインターンシップ生に来ていただき、2週間にわたるプログラムに取り組んでいただきました！ インターンシップ生の目線で、ポスト紹介や体験した業務内容、振り返りをまとめてもらいました。 この記事では、それらをポストごとにご紹介します。 インターンシップ生目線のよりリアルな体験記を通して、次回以降に応募を検討される方の一助となれば幸いです。 【D1】CSIRTでのサイバー攻撃への対応実践と高度分析 ポスト紹介① 体験した業務内容① 演習1日目 演習2日目 振り返り① ポスト紹介② 体験した業務内容② Linuxのフォレンジック演習 Windowsのフォレンジック演習 振り返り② 【D10】CSIRT運用業務の効率化に向けたDX化 ポスト紹介 体験した業務内容 振り返り 【D11】CSIRTで脅威インテリジェンスをハンドリングするセキュリティエンジニア ポスト紹介 体験した業務内容 振り返り 【D12】ネットワークセキュリティ製品を活用したデータ/脅威分析、実装および運用高度化 ポスト紹介 体験した業務内容 NDR製品を用いた模擬攻撃の詳細調査 NDR製品における一次調査の手順書作成 振り返り 【D13】攻撃者視点で社内防御力を高めるセキュリティエンジニア ポスト紹介 体験した業務内容 ペネトレーションテストの実施とWriteup作成 改善提案表の作成 MITRE ATT&CKマッピング 振り返り おわりに 【D1】CSIRTでのサイバー攻撃への対応実践と高度分析 D1ポストは、2つのチームの合同ポストです。それぞれのチームの業務を体験していただきました！ ポスト紹介① EDR（Endpoint Detection and Response） 1 やSIEM（Security Information and Event Management） 2 からのアラート対応、および社内外から報告されたインシデントへの対応が体験できるポストです。インターンシップでは、隔離された検証環境において模擬攻撃を実施し、EDRのアラート精度を検証しました。 体験した業務内容① MITRE社が開発し、現在はApache Software Foundationにおいて開発が進められている攻撃シミュレーションツール「 Apache Caldera 」を用い、さまざまな攻撃手法を再現しました。そのうえで、「どのような操作やコマンドがEDRに検知されるのか」「逆に、どのような挙動が検知されにくいのか」という観点から分析をしました。 演習環境は、攻撃するためのVM1台と、攻撃対象となるVM2台で構成されていました。 演習1日目 1日目は、模擬攻撃によって発生したEDRのアラートを分析し、インシデント対応を体験しました。 具体的には、提示された4件のアラートについて、以下の観点から調査・検討しました。 なぜアラートが発生したのか EDRはどのような挙動を検知したのか どのような脅威が考えられるのか 実際の運用ではどのような対応が必要になるのか 単にアラートの内容を確認するだけでなく、想定される脅威や必要となる対処を考えることで、インシデント対応担当者に求められる考え方を学ぶことができました。 演習2日目 2日目は、Apache Calderaを用いてオリジナルの攻撃シナリオを作成し、その挙動がEDRにどのように検知されるのかを検証しました。 攻撃シナリオを自ら設計することで、攻撃側の視点と防御側の視点の両方からセキュリティ対策を考えることができました。 また、実際にシナリオを実行して検知結果を分析することで、EDRがどのような振る舞いを重視して監視しているのか、理解を深めることができました。 今回追加した攻撃シナリオの例は以下のとおりです。 ネットワークをスキャンして、隣接IPを調査 見つけたIPに対してポートスキャン cuppをcloneして、パスワードリストを作成 作成したリストを使ってHydraでログイン試行 特定したパスワードでログイン 振り返り① 今回の演習を通じて、アラート対応業務への理解を深めることができました。実際の運用では重大なインシデントが発生することは多くなく、日々発生するアラートの中には誤検知が多いことを学びました。このことから、多数のアラートの中から誤検知を適切に判断し、迅速に対応することの重要性を理解しました。また、IoC（Indicators of Compromise） 3 だけでなくIoA（Indicators of Attack） 4 に着目した検知の考え方にも触れ、どのような振る舞いをルール化すれば効果的な検知につながるのかを考える良い機会となりました。 今回の演習から、実際の環境におけるEDRの具体的な使い方や運用方法を学ぶことができました。また、自ら攻撃シナリオを作成し、発生したアラートを調査するという一連の流れを経験しました。この過程で、攻撃側と防御側が相互に技術を高め合うことの重要性を確認できました。今後は、攻撃側と防御側、双方の視点から捉えて技術を高めていきたいと思います。 EDRを実際に使用することで、これまで不明瞭であったCSIRTの具体的な業務プロセスについて理解を深められました。また、実際の対応においては、Red Teamの視点を持つことの重要性と、チーム内での連携やコミュニケーションが不可欠であることを学びました。今回の経験を踏まえ、今後の学習においてもApache Calderaを日常的に活用していきたいと考えています。 ポスト紹介② Blue Teamの一員として、デジタルフォレンジック調査や脆弱性管理などを実施する業務です。インターンでは、フォレンジック演習に取り組みました。 体験した業務内容② 本ポストの業務では、LinuxとWindowsを対象としたフォレンジック演習に取り組みました。 Linuxのフォレンジック演習 Linuxのフォレンジック演習では、DrupalのRCE（Remote Code Execution）脆弱性 を悪用した攻撃を題材として扱いました。RCEは、攻撃者がネットワーク越しに対象サーバやアプリケーション上で任意のコードを実行できてしまう脆弱性です。 演習では、Apacheのアクセスログや認証ログ、コマンド実行ログなどを調査し、攻撃の痕跡や侵入後の活動を分析しました。 集めた攻撃の証拠を時系列で確認することで、攻撃者によるコマンド実行や権限昇格、バックドア用のユーザ作成による永続化、Webシェルの設置まで、攻撃の流れを追跡しました。 Windowsのフォレンジック演習 Windowsのフォレンジック演習では、被疑端末から取得した各種アーティファクト（システムや利用者の活動履歴を示すデータ）を調査しました。 具体的には、ファイル操作の履歴を確認できる「MFT（Master File Table）」、Windowsのイベントを記録する「イベントログ」、実行されたプログラムの情報が残る「Prefetch」や「Amcache」、ユーザ操作の痕跡を確認できる「UserAssist」、ネットワーク通信を分析する「PCAP（Packet Capture）」などを用いて、不審な活動の有無を分析しました。 その結果、ユーザ端末上でコードエディタ製品の正規ツールを装ったマルウェアが実行され、端末のユーザ情報やIPアドレスなどの情報が攻撃者側へ送信されていたことを確認しました。 振り返り② LinuxおよびWindows環境のフォレンジック演習を通じて、インシデント発生時にどのログを優先的に確認すべきか、またどのような観点で調査を進めるべきかを再確認できました。時系列で事象を整理する重要性は理解していましたが、ログから痕跡を効率的に見つけ出す視点も重要であると学びました。特にWindowsでは、UserAssistだけでなくPrefetchやAmcacheなど複数のアーティファクトを組み合わせて分析することで、プログラムの実行時刻や実行回数をより正確に把握できることが印象的でした。答え合わせや他の参加者との議論を通じて、知らなかったアーティファクトや調査手法についても学ぶことができ、大変有意義な経験となりました。 演習を通じて、フォレンジック調査に必要となる各種ツールの用途や使用方法を学ぶとともに、実際の解析に至るまでの具体的な業務フローを把握できました。また、社員の方からの解説を聞く中で、ログから抽出・推測できる情報や調査手法について、自分のフォレンジックに関する知識は十分でないと痛感しました。今回の経験を踏まえ、今後はログ分析やフォレンジックに関する知見をさらに広げ、継続して学習に取り組みたいと考えています。 フォレンジック演習を通じて、フォレンジックの実務についてより具体的な理解を得ることができました。特に、参加者3名がそれぞれ異なる手法を用いて調査を進めている点を確認でき、調査における多角的な視点の重要性を認識しました。また、実際の過程を通じて、OSの仕組みをはじめとする、自身に不足している知識が明確になりました。今後はこれらの領域についても継続的に学習を進め、技術的な理解を深めていきたいと考えています。 【D10】CSIRT運用業務の効率化に向けたDX化 ポスト紹介 セキュリティオペレーションの効率化と高度化を目的とした開発業務を体験しました。 具体的には、①アラートメールの自動チケット化と、②問い合わせ時の通知機能の自動化に取り組みました。 体験した業務内容 まず、①アラートメールの自動チケット化について説明します。 メール受信ボックスにセキュリティアラートメールが届いた際に、メールの内容を抽出してチケット管理システムに自動起票し、添付ファイルを保管領域に保存したうえで、コミュニケーションツールにアラートの発生を知らせる通知システムを開発しました。 今回は、インシデントレスポンスに必要な情報かどうかという観点から、以下の3種類のメールごとに実装を分けました。 初報メールの場合、新たにチケットを作成し、通知する 更新メールの場合、既存のチケットを更新し、通知する 週間レポートメールの場合、何もせずに処理を終了する 本格的なシステムの作成前に、まず2人で要件定義の洗い出しを行いました。 これまで要件定義の経験がなかったため、実際に作成しながら学ぶことが多くありました。 特に、エラーなどの異常系をどこまで想定して記載すべきかについては、2人で悩みながら検討を重ね、試行錯誤しながら完成させました。 要件定義を作成したことで、今後何を作成しなければならないのかが明確になりました。 その後は、要件定義の内容を基に各自でフローチャートを作成し、処理の流れや実装内容への理解を深めることができました。 技術的に不明で調査が必要な箇所には吹き出しでメモを残し、開発前にモックアップを作成して技術調査をしました。 本実装では、これまで整理してきた要件や調査結果を基に、自動化ツールを用いてワークフローを作成しました。 アラートメールに含まれる情報を抽出し、チケット管理システムへ必要な情報を自動で起票するとともに、コミュニケーションツールへの通知を自動化する仕組みを構築できました。 実装の過程では、初めての自動化開発ということもあり、エラー対応や処理の実装方法に悩む場面が多くありました。 しかし、その都度原因を調査し、設定や処理内容を見直しながら試行錯誤を重ねることで、ひとつひとつ課題を解決できました。最終的には要件を満たすワークフローを完成させることができ、技術的な成長を実感するとともに、大きな達成感を得ることができました。 次に、②問い合わせ時の通知機能の自動化について説明します。 ①で自動化ツールを用いた開発への理解を深めた後は、それまでに学んだ知識や経験を活かし、チケットシステムの利用者から送信される問い合わせをフォームとリストで管理し、新たな問い合わせが届いた際にチケットシステムの運用担当者へ通知するシステムを開発しました。 前回の開発で得た知見を活用しながら設計・実装を進めることで、サービス間の連携や自動化について、さらに理解を深めることができました。 また、問い合わせフォームが送信されると、その内容が管理リストに投稿されます。 このとき、コミュニケーションツールへの通知だけでなく、状態ステータスも変更する仕様を実装しました。 新規の問い合わせが登録されると、問い合わせ内容を含む通知が関係者へ自動送信される仕組みを実装しました。 また、通知内のアクションボタンを操作することで、リストで管理している問い合わせの状態を「受付」から「対応中」へ、「対応中」から「完了」へ更新できるようにしました。 これにより、問い合わせ対応状況の管理を効率化し、運用担当者が迅速に対応できる仕組みを実現できました。 振り返り 今回のインターンシップで、会社での開発は、他のチームの方々や開発したツールを使用する利用者、今後新たに機能を拡張する他の開発者のことまで考えながら進めるものであると、身をもって実感しました。特に、実装方法が複数考えられる場合に、どのパターンを選ぶかの判断基準が利用者や他の開発者にあることを知ることができ、インターンシップに参加してよかったと感じました。 2週間のインターンシップを通して、期間内に成果物を完成させるための時間・スケジュール管理の必要性や、業務を進めるうえでの情報共有・コミュニケーションの重要性、トライアンドエラーを繰り返して問題を解決する力を理解し、身につけました。この経験を活かし、さらなる自己研鑽を進め、応用や拡張にも適応できる人間に成長したいと考えています。 【D11】CSIRTで脅威インテリジェンスをハンドリングするセキュリティエンジニア ポスト紹介 サイバー攻撃による社内システムへのインシデント被害の最小化と未然防止をミッションとしている、セキュリティエンジニアのポストです！ チーム内で行っている業務はさまざまですが、代表例として、公開情報から脅威アクターの動きを観測しています。 また、日々更新される脆弱性情報の中からリスクの高いものをレポーティングし、関連部署へシステムのバージョン管理やアップデートを促しています。 体験した業務内容 社内システムに関連する脆弱性が公開された際に、他部署へ注意喚起するためのインテリジェンスレポートを、ClaudeのSkillを用いて自動的に作成できるよう実装しました。 フロンティアAIの登場により脆弱性の報告数が増加し、対応に追われている組織も多く、私が参加したチームでも同様の課題を抱えていました。 この課題を解決するために、取り上げるに値する脆弱性のスコープごとにSkillをオーケストレーションすることで、網羅性を確保しつつ利用者の調査業務の時間短縮につながるように設計した点がポイントです。 実際にこのSkillを使用することによって、業務上で改善された点は3つあります。 1つめは、インテリジェンスレポートの品質の担保です。これまでは各メンバーがそれぞれLLMを用いてレポートの草案を作成していましたが、プロンプトの与え方や参照ソースの選び方がメンバーごとに異なるため、同じCVEを扱っても出来上がる草案の粒度や観点にばらつきが生じていました。 今回作成したSkillでは、収集すべき情報源・記事の構成・文体指針をあらかじめ定型化したことで、誰が実行しても一定の水準を担保できる状態にしました。 2つめは、レビュー工数の削減です。従来はレビュアーが草案を受け取ってから複数回の指摘・修正のやり取りが発生していましたが、Skill側で文体チェック、参照リンクの生存確認、未確認項目の可視化までを自動で行うようにしたため、レビュー工数が実質1回で済むようになり、レポート作成全体に要する時間が大幅に短縮されました。 最後に、作成コストの安さです。1本のインテリジェンスレポートを生成するのにかかる費用はOpus 4.7で500〜600円程度に収まっており、頻繁に運用しても負担にならない水準を実現できました。 振り返り 本課題を始める前に、脅威インテリジェンスとは何かを知るため、5つのSTEPからなる総合演習で構成されるコースワークに取り組みました。 その際、インテリジェンスという抽象的で説明しがたい概念を理解するため、アメリカ統合参謀本部が公開している「JP 2-0 5 」を読みましたが、「インテリジェンスとは何か」がますます理解できなくなり困りました。 理解が及ばない部分については、抽象的な概念をつかむために脅威インテリジェンスの教科書を読み込みました。インターンシップ期間中は四苦八苦しましたが、基礎的かつ重要な事項を、苦しみながらも自分の言葉で表現できたときはとても嬉しかったです。 本課題では、チームの日常業務の効率化とリスクの明確化を目標に、ClaudeのSkillでインテリジェンスレポートの自動生成に取り組みました。 文章だけで見ると「あまりたいした実装ではないのでは……？」と思われるかもしれません。しかし今回の実装は、現場でも「何が課題なのか、何ができると嬉しいのか」を要件定義しきれていない暗黙知を扱うものであり、私個人で完結できる内容ではありませんでした。 そのため、メンターの方々や上長を含むチームメンバーと議論を重ねながら進める必要があり、相応の時間を要する難易度の高い取り組みとなりました。 要件を定義しづらい課題にチームメンバーと協働しながら取り組んだ経験は、これまでの個人開発では決して得られないものであり、本課題を通して課題設定力と、短い期限のなかで冷静に優先順位を判断し物事を推進する力が身についたと感じています。 最後に、本インターンシップ全体の学びを書いて終わりたいと思います。脅威インテリジェンスは、科学的な検証によって確実性が保証される領域ではありません。仮説から捕捉できた脅威はエッジケースかもしれませんし、逆に何もわからなくても、それが現時点でのベストエフォートかもしれません。 だからこそ、直感的な洞察と論理的な分析の双方から解釈した情報を意思決定に活かすことがアナリストの責務ではありますが、これを成し得るには蓋然性を正しく判定するためのプロセスを踏み続ける必要があり、この営みを継続することの難しさを学びました。 【D12】ネットワークセキュリティ製品を活用したデータ/脅威分析、実装および運用高度化 ポスト紹介 本ポストでは、新たに導入するセキュリティ製品の評価や、組織で活用していくための運用支援業務を行っています。 その中で私は、ネットワーク上の不審な通信を検知・分析するNDR（Network Detection and Response）において、模擬攻撃を詳細に調査し、その知見を誰もが活用できるよう手順書の作成に取り組みました。 体験した業務内容 NDR製品を用いた模擬攻撃の詳細調査 NDRで検知されたアラートの詳細調査を実施しました。アラートに関連する通信を条件で絞り込みながら確認し、実際にどのような攻撃行動が行われていたのかを分析しました。 調査を通じて、得られた情報をもとに攻撃者の行動を推測し、攻撃のシナリオを組み立てながら通信内容を分析することの重要性を学びました。 上記の図は、アラートに関連する通信をSQL文を用いてフィルタリングした結果です。 NDR製品における一次調査の手順書作成 NDRでアラートが発生した際に、一次調査で使用する手順書を作成しました。手順書の作成にあたっては、製品の機能や操作方法を整理するだけでなく、実際にアラートが発生した際の調査の流れを想定しながら内容を検討しました。 また、利用者が必要な情報に迷わずたどり着けるよう、実際の運用で求められる確認事項や判断材料を意識して文書化を行いました。 上記の図は、実際に作成した手順書の一部です。手順書の作成にあたっては、実際のNDRの操作画面のスクリーンショットを使用し、図中の確認箇所をナンバリングして本文との対応関係を明確にしました。 また、模擬攻撃の詳細調査を実施した際に理解や判断に迷った箇所については、調査時の観点や確認ポイントを補足するなど、利用者が迷わず調査を進められるよう工夫しました。 振り返り 今回のインターンシップでは、セキュリティ製品そのものだけでなく、組織における運用についても学ぶことができました。特に手順書の作成では、操作方法をまとめるだけでなく、その情報がどのように活用されるのかを意識する必要がありました。 また、実際の運用では他組織との連携も求められるため、利用者の視点で必要な情報を整理し、分かりやすく伝えることの重要性を学びました。 今後は、本インターンシップで得たセキュリティ製品の知識や運用設計の考え方を活かし、実際の運用を見据えたシステム設計や仕組みづくりができるエンジニアを目指したいと考えています。 【D13】攻撃者視点で社内防御力を高めるセキュリティエンジニア ポスト紹介 NTTドコモビジネス社内の組織やサービスに対して脅威ベースのペネトレーションテストを実施し、セキュリティ対策の状況をRed Teamの立場で継続的にチェックする業務を行っているチームに所属させていただきました。 具体的には、攻撃ツールの検証や環境構築、攻撃シナリオの整備、改善提案などに従事しました。 体験した業務内容 ペネトレーションテストの実施とWriteup作成 VulnHubから入手した脆弱なLinuxマシン2台に対してペネトレーションテストを実施し、Writeupを作成しました。 ペネトレーションテストは、情報収集、脆弱性調査、初期侵入、権限昇格の順で行いました。 1台目は、DrupalというCMS（Content Management System） 6 のRCE脆弱性を悪用して初期侵入を実施し、SUIDの設定不備を悪用して権限昇格をしました。 2台目は、2台目は、WordPressのプラグインの脆弱性を悪用してサーバ上のファイルを読み取るLFI（Local File Inclusion） によりパスワード情報を取得できました。LFIは、本来アクセスできないサーバ内のファイルを読み取れてしまう脆弱性です。 その後、保存されていたパスワードをリバースブルートフォースすることで侵入できました。 また、実施した攻撃手法のうち、チームのナレッジ集になかったものを追加させていただきました。 改善提案表の作成 発見した脆弱性について、仮想の会社で脆弱性を悪用された際に想定されるリスクや改善案などをまとめた改善提案表を作成しました。 メンター社員の方からアドバイスをいただきながら、実際の業務に近い改善提案をできました。 MITRE ATT&CKマッピング MITRE ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge） は、サイバー攻撃者が用いる戦術や攻撃手法を整理したナレッジベースです。 本演習では、実施した攻撃をMITRE ATT&CK Navigator上でマッピングし、どのような攻撃手法が用いられたかを可視化しました。 濃い赤は2台に共通していた攻撃手法、薄い赤は片方のマシンでのみ使用した攻撃手法です。 振り返り 今回のインターンシップを通じて、本ポストでは攻撃を成功させるための技術力だけでなく、運用側にどのような改善を促すかを考える提案力も重要であると学びました。特に改善提案表の作成では、場当たり的な対策を提示するだけでなく、脆弱性を生まないために業務プロセスをどのように改善していくべきかまで踏み込んで考えることができました。 また、Writeupの作成では、相手に伝わりやすいレポートの作成方法についても学ぶことができました。 おわりに 本記事では、2週間のプログラムに取り組んでいただいたインターンシップ生の皆さまに、それぞれのポストでの業務と、そこで得た学びを綴っていただきました。ご多忙のなか快くご協力いただき、ありがとうございました。 本記事を読んで少しでも興味を持たれた29卒以降の方は、ぜひ来年度のインターンシッププログラムへご応募ください。皆さまとお会いできることを楽しみにしています！ Endpoint Detection and Response。PCやサーバなどの端末上の動作を継続的に記録・監視し、不審な挙動の検知と、その後の調査・対応を支援する仕組みです。 ↩ Security Information and Event Management。各種機器やソフトウェアが出力するログを一元的に集約し、相関分析によって脅威の兆候を検知する仕組みです。 ↩ Indicator of Compromise（侵害指標）。マルウェアのハッシュ値や通信先のIPアドレス・ドメインなど、侵害が発生したことを示す個別の痕跡を指します。 ↩ Indicator of Attack（攻撃指標）。個々の痕跡ではなく、攻撃者が目的を達成するまでにとる一連の振る舞いに着目した指標で、進行中の攻撃の兆候を捉えることを狙いとします。 ↩ Joint Publication 2-0「Joint Intelligence」。アメリカ統合参謀本部議長の指揮のもとで整備される統合ドクトリンのうち、情報（インテリジェンス）分野の基幹文書にあたります。統合作戦における情報の役割や基本原則、情報が生み出されるまでの一連のプロセスがまとめられています。文書は 統合参謀本部のサイト で公開されています。 ↩ Contents Management System。Webサイトのテキストや画像などのコンテンツを、HTMLを直接編集することなく作成・管理・公開できるようにするシステムです。本記事に登場するDrupalやWordPressがこれにあたります。 ↩

弊社で毎月開催し、 PHP エンジニアの間でご好評をいただいている PHP TechCafe。 2022年11月のイベントでは「 PHP フレームワーク 」について語り合いました。 弊社メンバーがピックアップした PHP の代表的な フレームワーク ４種について、以下のShowNoteをベースに、参加者の皆様のご意見も伺いながら学んでいきました。今回はその内容についてレポートします。 rakus.connpass.com hackmd.io フレームワークとは 代表的なPHPフレームワーク Laravel Symfony CakePHP Slim 機能比較 ルーティング Laravel Symfony CakePHP Slim まとめ セッション管理 Laravel Symfony CakePHP Slim まとめ リクエスト管理 Laravel Symfony CakePHP Slim まとめ エラーハンドリング Laravel Symfony CakePHP Slim DBサポート Laravel Symfony CakePHP Slim 最後に フレームワーク とは まず初めに、 フレームワーク とは、 アプリケーション開発においてよく利用される機能をあらかじめ備えた枠組み のことです。 もう少し具体的に説明すると、以下の通りです。 Webアプリケーション フレームワーク 動的な ウェブサイト、Webアプリケーション、 Webサービス の開発をサポートするために設計されたアプリケーション フレームワーク Web開発で用いられる共通した作業に伴う労力を軽減する データベースへのアクセス テンプレートエンジン セッション管理 何故 フレームワーク が必要なのか？ 開発速度向上 Webアプリケーション開発でよく利用する処理（セッション管理やDBアクセス、 Cookie など）が既に用意されているため、それらを再利用するだけで開発が進められる セキュリティ対応 脆弱性 が見つかった場合に修正版がリリースされる 開発ルールの順守 フレームワーク のルールに従って作成することが強いられる反面、開発チーム全体で共通のルールで開発できるため、ルールに逸脱するようなコードが生まれにくい ここでは、「セキュリティに関わる実装を自前で組むメリットは少ないため、実績のある フレームワーク を利用することが一番の正攻法ではないか」といった意見が挙がっていました。 代表的な PHP フレームワーク 次に、事前に弊社メンバーが抜粋した、代表的な PHP フレームワーク それぞれの設計思想について語り合いました。 （抽出対象や並び順に意図はございません） Laravel laravel.com プログレ ッシブ フレームワーク どのような規模や段階の Web アプリケーションにも対応できる フレームワーク の概念 依存性注入、 単体テスト 、キュー、リアルタイム イベント などのための堅牢なツールを提供 スケーラブルな フレームワーク システム規模や利用負荷などの増大に対応できる Laravel アプリケーションは、1 か月あたり数億のリク エス トを処理するように簡単にスケーリングされている コミュニティ フレームワーク コミュニティの活動が活発であり、意見交換も頻繁に行われている 参加者からは「確かにイー ジー なイメージがあり、何でもできて簡単。」といった意見や、「依存性注入や 単体テスト のために独自に拡充された機能が提供されており、色々出来て便利」といった意見が挙がりました。Laravleにはサー ビスコ ンテナと呼ばれる機能が備わっているため、依存性注入を簡単に行うことができたり、 ユニットテスト を考慮して構築されていることがその理由となります。 Symfony symfony.com 作成された コンポーネント を組み合わせて、 フルスタックフレームワーク を作成することもマイクロサービスを作成することも可能 開発者の目的に応じて規模を変えることができることが特徴 コンポーネント が標準化されており、アプリケーションが成熟しても使用したい コンポーネント を自由に導入することができる Java の Spring Framework や Ruby の Ruby on Rails の影響を受けている Symfony コンポーネント は Drupal , Prestashop , Laravel 　で利用されている ここでは、 Symfony 自体がLaravelの中で使われているという点について活発にコメントが飛び交いました。 「 Symfony のリリースが遅れることによってLaravelにも影響が出たケースがあった」という声や、「Laravelのリリース頻度が Symfony のバージョンアップに依存するような形になったということを過去に記事で見た」という声です。 現時点の最新バージョンであるLaravel9についても、 Symfony の コンポーネント に依存していることが要因となりLTS（※LTSはLong Term Supportの略で長期サポートを意味）がなくなったりと、実際に様々な影響を及ぼしていることから、このような声が多く挙がっているようです。 CakePHP cakephp.org 「ケーキを焼くくらい簡単に開発できる」というコンセプトで設計されており、初心者向けであるといえる Ruby on Rails の概念の多くが取り入れられている 比較的小規模なWeb アプリ開発 向けである 「 MVC モデル」が採用されており、役割分担をさせて高速に開発を進められる ここでは、「 MVC に準拠しており、 命名 がすごく厳格だという印象がある」という意見が挙がりました。 Slim www.slimframework.com www.slimframework.com シンプルかつ強力な Web アプリケーションと API をすばやく作成するのに役立つ PHP マイクロ フレームワーク 必要なことだけを行う最小限のツール セットのみを提供 最小限の機能のみを持つため、ルールがシンプルで、開発の自由度が高く、学習コストが低い ここでは、マイクロ フレームワーク を謡っているという点について「テンプレートエンジンが標準で提供されておらず、細かな Bot 作成や小さな機能開発を行う際に利用しやすい」といった意見や、「自由に拡張できるという点がありがたい」といった意見が挙がりました。 機能比較 続いて、各 フレームワーク の基本的な利用方法に注目し、それぞれの特徴について比較しながらディスカッションを行いました。 ルーティング Laravel laravel.com ルートファイル デフォルトでは下記２つファイルにルーティングを定義する routes/web. php routes/ api . php 定義方法 UserControllerにindexメソッドを定義している場合、下記のように定義すると /user のパスに対して、UserControllerのindexメソッドが対応される <?php use App\Http\Controllers\UserController; Route :: get ( '/user' , [ UserController :: class , 'index' ]) ; 利用可能な ルーター メソッド <?php Route :: get ( $ uri , $ callback ) ; Route :: post ( $ uri , $ callback ) ; Route :: put ( $ uri , $ callback ) ; Route :: patch ( $ uri , $ callback ) ; Route :: delete ( $ uri , $ callback ) ; Route :: options ( $ uri , $ callback ) ; パラメータ <?php Route :: get ( '/posts/{post}/comments/{comment}' , [ CommentController :: class , 'show' ]) ; ここでは「 Route::get や Route::post のように、複数のHTTP動詞に対応したルートを登録できることが特徴的である」という意見が挙がりました。 Symfony routes.yaml に記載するパターン /lucky/number にアクセスすることで LuckyController の number メソッドにルーティングされる app_lucky_number : path : /lucky/number controller : App\Controller\LuckyController::number アノテーション または アトリビュート を利用するパターン(こちらが推奨) コントローラを以下の通り変更することで routes.yaml を作成しなくともルーティングが行われる <?php // src/Controller/LuckyController.php namespace App\Controller; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\Routing\Annotation\Route; class LuckyController { #[Route('/lucky/number')] public function number () : Response { $ number = random_int ( 0 , 100 ) ; return new Response ( '<html><body>Lucky number: ' .$ number . '</body></html>' ) ; } } ここでは「ルーティングの方法が複数ある」という点に注目が集まりました。 「デフォルトは routes.yaml だが推奨パターンは アトリビュート を使うパターンのようだ」といった声や、「サンプルコードのような アトリビュート を使うパターンが分かりやすい」といった声が挙がりました。 CakePHP book.cakephp.org routes.php に記載 　例： / にアクセスすると ArticlesController の index() メソッドを実行する <?php use Cake\Routing\Router; // スコープ付きルートビルダーを使用。 Router :: scope ( '/' , function ( $ routes ) { $ routes -> connect ( '/' , [ 'controller' => 'Articles' , 'action' => 'index' ]) ; }) ; // static メソッドを使用。 Router :: connect ( '/' , [ 'controller' => 'Articles' , 'action' => 'index' ]) ; 　 /articles/15 にアクセスすると ArticlesController の view(15) メソッドを実行する <?php $ routes -> connect ( '/articles/:id' , [ 'controller' => 'Articles' , 'action' => 'view' ] ) -> setPatterns ([ 'id' => '\d+' ]) -> setPass ([ 'id' ]) ; 　HTTPメソッドによって分けたいときは以下のような記述を行う <?php // GET リクエストへのみ応答するルートの作成 $ routes -> get ( '/cooks/:id' , [ 'controller' => 'Users' , 'action' => 'view' ] , 'users:view' ) ; // PUT リクエストへのみ応答するルートの作成 $ routes -> put ( '/cooks/:id' , [ 'controller' => 'Users' , 'action' => 'update' ] , 'users:update' ) ; ここでは「必ずしもルーティングは必要でなく、URLから勝手にクラスを推測してくれる」という点に注目が集まりました。 しかし、「知らないと迷いそうなので明記して欲しい」といった声もあり、やはり明示的に定義するのがベストだろうという考えに落ち着きました。 Slim www.slimframework.com get() ／ post() メソッドを使用 <?php $ app -> get ( '/books/{id}' , function ( $ request , $ response , array $ args ) { // Show book identified by $args['id'] }) ; <?php $ app -> post ( '/books' , function ( $ request , $ response , array $ args ) { // Create new book }) ; ここではルータメソッドが get() ／ post() であることから「Laravelと似ている」という意見が挙がりました。 まとめ ルーティングの利用方法に関して全体を見渡した後には、以下のような意見が挙がりました。 Symfony ： アトリビュート によるルーティングが特徴的 CakePHP ：ルーティングを記載せずとも フレームワーク で勝手に呼び出すクラスを推測してくれる点が特徴的 Laravel： Routes を見に行く必要があることが面倒である、 C# のルーティング定義に似ている 全般：どこで何をやっているのかが分かるルーティングの方法であることが望ましい composerのインストール／アップデートのように、1つの操作が複数の役割を持つような仕組みは分かりづらい セッション管理 続いて、セッション管理の方法について見ていきます。 Laravel laravel.com 設定ファイル config/session. php セッションの操作方法 グローバルセッションヘルパー と Requestインスタンス経由 の2つの方法がある 　　 　・グローバルセッションヘルパー <?php $ value = session ( 'key' ) ; 　　 　・Request インスタンス 経由 <?php public function show ( Request $ request , $ id ) { $ value = $ request -> session () -> get ( 'key' ) ; // } Symfony セッションの操作方法 RequestStack と RSessionInterface から取得する2つの方法がある RequestStack から取得するパターン セッションの設定は config/packages/framework.yaml に記載 HttpFoundation component を追加することで利用可能 その他の詳細 基本的な使い方 <?php use Symfony\Component\HttpFoundation\RequestStack; class SomeService { private $ requestStack ; public function __construct ( RequestStack $ requestStack ) { $ this -> requestStack = $ requestStack ; // Accessing the session in the constructor is *NOT* recommended, since // it might not be accessible yet or lead to unwanted side-effects // $this->session = $requestStack->getSession(); } public function someMethod () { $ session = $ this -> requestStack -> getSession () ; // stores an attribute in the session for later reuse $ session -> set ( 'attribute-name' , 'attribute-value' ) ; // gets an attribute by name $ foo = $ session -> get ( 'foo' ) ; // the second argument is the value returned when the attribute doesn't exist $ filters = $ session -> get ( 'filters' , []) ; // ... } } SessionInterface から取得するパターン SessionInterface でタイプヒントしてコントローラ引数に渡すだけ 基本的な使い方 <?php use Symfony\Component\HttpFoundation\Response; use Symfony\Component\HttpFoundation\Session\SessionInterface; // ... public function index ( SessionInterface $ session ) : Response { // stores an attribute for reuse during a later user request $ session -> set ( 'foo' , 'bar' ) ; // gets the attribute set by another controller in another request $ foobar = $ session -> get ( 'foobar' ) ; // uses a default value if the attribute doesn't exist $ filters = $ session -> get ( 'filters' , []) ; // ... } CakePHP book.cakephp.org PHP のネイティブ session 拡張上に、ユーティリティ機能のスイートとラッパーを提供 設定 　・データベースセッション 　　・セッションをデータベースに保持することを指定 　　・セッション保持するためのカスタムモデルを定義することもできる(model => 'CustomSessions') <?php 'Session' => [ 'defaults' => 'database' , 'handler' => [ 'engine' => 'DatabaseSession' , 'model' => 'CustomSessions' ] ] 　　・キャッシュセッション 　　　・CacheSession クラスをセッション保存先として 指定 <?php Configure :: write ( 'Session' , [ 'defaults' => 'cache' , 'handler' => [ 'config' => 'session' ] ]) ; セッションの利用 リク エス トオブジェクトを呼び出せる場所ならどこでも呼び出せる Controllers Views Helpers Cells Components <?php $ name = $ this -> getRequest () -> getSession () -> read ( 'User.name' ) ; // 複数回セッションにアクセスする場合、 // ローカル変数にしたくなるでしょう。 $ session = $ this -> getRequest () -> getSession () ; $ name = $ session -> read ( 'User.name' ) ; 利用するメソッド Session::read($key) Session::write($key) Session::check($key) Session::destroy() Slim なし まとめ セッションについては、それぞれの フレームワーク で利用方法が多岐に渡りました。 ここでは、 CakePHP について、「セッションの参照に Get ではなく Read になっているのは何故なのか？」といったコメントや、Slimにはそもそも実装されていない点について、「それがSlimの良いところであり、必要であればcomposerで導入すればよい」といったコメントが挙がっていました。 リク エス ト管理 Laravel laravel.com <?php $ name = $ request -> input ( 'name' ) ; $ name = $ request -> query ( 'name' ) ; Laravelでは Request クラスの インスタンス から取得します。 Symfony symfony.com <?php use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; public function index ( Request $ request ) : Response { $ request -> isXmlHttpRequest () ; // is it an Ajax request? $ request -> getPreferredLanguage ([ 'en' , 'fr' ]) ; // retrieves GET and POST variables respectively $ request -> query -> get ( 'page' ) ; $ request -> request -> get ( 'page' ) ; // retrieves SERVER variables $ request -> server -> get ( 'HTTP_HOST' ) ; // retrieves an instance of UploadedFile identified by foo $ request -> files -> get ( 'foo' ) ; // retrieves a COOKIE value $ request -> cookies -> get ( 'PHPSESSID' ) ; // retrieves an HTTP request header, with normalized, lowercase keys $ request -> headers -> get ( 'host' ) ; $ request -> headers -> get ( 'content-type' ) ; } Symfony もLaravelと同じ様に Request クラスの インスタンス から取得します。 CakePHP <?php $ controllerName = $ this -> request -> getParam ( 'controller' ) ; // URL は /posts/index?page=1&sort=title の場合に page を取得するとき $ page = $ this -> request -> getQuery ( 'page' ) ; //　POSTデータにアクセスするとき $ title = $ this -> request -> getData ( 'MyModel.title' ) ; CakePHP もLaravel、 Symfony と似たイメージです。 Slim www.slimframework.com <?php use Psr\Http\Message\ResponseInterface as Response; use Psr\Http\Message\ServerRequestInterface as Request; use Slim\Factory\AppFactory; require __DIR__ . '/../vendor/autoload.php' ; $ app = AppFactory :: create () ; $ app -> get ( '/hello' , function ( Request $ request , Response $ response ) { $ response -> getBody () -> write ( 'Hello World' ) ; return $ response ; }) ; $ app -> run () ; セッション管理は実装されていませんでしたが、リク エス ト管理はSlimにもちゃんと実装されています。 まとめ ここでは、「いずれもRequestクラスの インスタンス から取得するという点において、だいたいどれも似たような形である」といった意見や、「これが フレームワーク の大本みたいな感じがする」といった意見が挙がりました。 Webアプリケーションの基本となる部分であることからも、それぞれの フレームワーク に大きな差はないようでした。 エラーハンドリング Laravel readouble.com App\Exceptions\Handler クラスによって、アプリケーションが投げるすべての例外がログに記録され、ユーザーへレンダーされる エラーハンドリングのカスタマイズ Handler クラスは、カスタム例外レポートと レンダリング コールバックを登録できる register メソッドを持っている。 reportable メソッドで、例外をさまざまな方法で報告できる。（エラー監視ツールに登録するなど。デフォルトではログに記録される。） renderable メソッドで、特定の例外に対して、個別に レンダリング 方法を指定することができる。(デフォルトでは例外はHTTPレスポンスに変換される) HTTPエラーが返された場合、 resources/views/errors 下の HTTPステータスコード 名のbladeファイルが レンダリング される（ 404.blade.php など） <?php use App\Exceptions\InvalidOrderException; /** * アプリケーションの例外処理コールバックを登録 * * @return void */ public function register () { $ this -> reportable ( function ( InvalidOrderException $ e ) { // 例外を報告 }) ; $ this -> renderable ( function ( InvalidOrderException $ e , $ request ) { return response () -> view ( 'errors.invalid-order' , [] , 500 ) ; }) ; } Laravelの場合、例外を投げた際にデフォルトのものを使うか別のカスタマイズされたものを使うか振り分けることができます。 例えば、404エラーの場合は 404.blade のように定義しておけば、自動で読み込んで画面に表示してくれます。 Symfony symfony.com github.com エラーが 404 Not Found エラーであろうと、コードで何らかの例外をスローすることによってトリガーされた致命的なエラーであろうと、すべてのエラーを例外として扱う。 組み込みの Twig エラーレンダラーを使用して、デフォルトのエラーテンプレートをオーバーライド可能。 composer require symfony/twig-pack これらのテンプレートをオーバーライドするには、標準の Symfony メソッドを使用し て、バンドル内にあるテンプレートをオーバーライドし、それらを templates/bundles/TwigBundle/Exception/ ディレクト リに配置する Copy templates/ └─ bundles/ └─ TwigBundle/ └─ Exception/ ├─ error404.html.twig ├─ error403.html.twig └─ error.html.twig # All other HTML errors (including 500) ここでは Twig に関して、デフォルトのエラーテンプレートをオーバーライドする際の利用方法が分かり易いといったコメントが挙がりました。 CakePHP book.cakephp.org <?php * ErrorController にてエラーページを描画 namespace App\Controller\Admin; use App\Controller\AppController; use Cake\Event\EventInterface; class ErrorController extends AppController { /** * Initialization hook method. * * @return void */ public function initialize () : void { $ this -> loadComponent ( 'RequestHandler' ) ; } /** * beforeRender callback. * * @param \Cake\Event\EventInterface $event Event. * @return void */ public function beforeRender ( EventInterface $ event ) { $ this -> viewBuilder () -> setTemplatePath ( 'Error' ) ; } } ここでは、「Cakeの場合はデフォルトのエラーテンプレートをオーバーライドするというより Controller をそれぞれ作るイメージだ」とのコメントがありました。 Slim www.slimframework.com slimが用意したエラー画面を出すかどうかを選択できたり、カスタムエラー画面を表示するなど柔軟な設定が可能 <?php use Slim\Factory\AppFactory; require __DIR__ . '/../vendor/autoload.php' ; $ app = AppFactory :: create () ; /** * The routing middleware should be added earlier than the ErrorMiddleware * Otherwise exceptions thrown from it will not be handled by the middleware */ $ app -> addRoutingMiddleware () ; /** * Add Error Middleware * * @param bool $displayErrorDetails -> Should be set to false in production * @param bool $logErrors -> Parameter is passed to the default ErrorHandler * @param bool $logErrorDetails -> Display error details in error log * @param LoggerInterface|null $logger -> Optional PSR-3 Logger * * Note: This middleware should be added last. It will not handle any exceptions/errors * for middleware added after it. */ $ errorMiddleware = $ app -> addErrorMiddleware ( true , true , true ) ; // ... $ app -> run () ; ここでは、Slimにはテンプレートエンジンがないことから、「用意したエラー画面を出すかカスタムエラーを出すか」であり、リク エス ト時に Add Error Middleware の設定を行うことでエラーハンドリングを有効／無効化が制御できるという説明がありました。 DBサポート Laravel readouble.com サポートされているDB MariaDB MySQL PostgreSQL SQLite SQL Server DBへのアクセス方法 　・DB ファサード $users = DB::select('select * from users where active = ?', [1]); 　・クエリビルダ $users = DB::table('users')->where('active', $isActive)->get(); 　・Eloquent $users = User::where('active', $isActive)->get(); ここでは、「LaravelではEloquentを利用するの良いだろう」という意見が挙がりました。 「様々なブログでも紹介されている」とう点や、「 SQL を知っていると直感的で分かり易い」といったコメントが挙がっていました。 Symfony symfony.com Doctrine(ORM)を使用 composer require doctrine maker インストールが完了すると .env ファイルにデータベースへの接続設定に関する項目が書き足される DATABASE_URL の箇所を接続するデータベースに合わせて書き換える DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name php bin/console doctrine:database:create エンティティクラスを作成する symfony console make:entity hoge CakePHP SELECT文の実行 <?php use Cake\Datasource\ConnectionManager; $ connection = ConnectionManager :: get ( 'default' ) ; $ results = $ connection -> execute ( 'SELECT * FROM articles' ) -> fetchAll ( 'assoc' ) ; INSERT文の実行 <?php use Cake\Datasource\ConnectionManager; use DateTime; $ connection = ConnectionManager :: get ( 'default' ) ; $ connection -> insert ( 'articles' , [ 'title' => 'A New Article' , 'created' => new DateTime ( 'now' ) ] , UPDATE文の実行 <?php use Cake\Datasource\ConnectionManager; $ connection = ConnectionManager :: get ( 'default' ) ; $ connection -> update ( 'articles' , [ 'title' => 'New title' ] , [ 'id' => 10 ]) ; DELETE文の実行 <?php use Cake\Datasource\ConnectionManager; $ connection = ConnectionManager :: get ( 'default' ) ; $ connection -> delete ( 'articles' , [ 'id' => 10 ]) ; Slim なし 最後に 今回は PHP の主要な フレームワーク について、様々な観点から見比べてみましたがいかがでしたでしょうか？ どの フレームワーク にも様々な特徴がありますが、チーム特性や作成するアプリケーションによっても採用する フレームワーク は変わってくると思います。 基本的な部分についてはどれも使い方は同じで、感覚的に使えるようになっているため、実際に触りながら色々と比べて見ると面白そうですね。 ShowNoteの方には「バリデーション」や「 マイグレーション 」についての比較も行っていますので是非ご覧になってください。 hackmd.io 「 PHP TechCafe」では今後も PHP に関する様々なテーマのイベントを企画していきます。皆さまのご参加をお待ちしております。 connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、主催イベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com