HTTPS（SSL/TLS）暗号化について

はじめに 皆さんこんにちは、オプスイン開発エンジニアの新川です。 この記事では、ウェブサービスに関わる上で基本中の基本のセキュリティともいえるHTTPSについて解説します。   HTTPSとは HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信をより安全に行うためのプロトコルです。HTTPとは別のプロトコルで、ウェルノウンポートも異なります。（HTTPは80番ポート、HTTPSは443番ポート） HTTPSを利用することにより、ウェブサイトをホスティングする場合に以下のようなメリットがあります。   改竄、盗聴などの攻撃を防ぐことができる HTTPSを利用する場合、ウェブブラウザからウェブサーバまでの通信が暗号化されます。これにより、例えば利用者がクレジットカード情報等をサーバに送信する場合でも、通信の盗聴や送受信データの改ざんを防ぐことができます。   なりすましの攻撃を防ぐことができる 「なりすまし」とはどういう物かというと、たとえばウェブサイトの閲覧者が銀行のサイトにアクセスして口座情報を入力するようなケースで、悪意のある物が銀行のページそっくりなサイトを用意し、そこにアクセスさせて個人情報を盗み取るような攻撃手段のことです。 HTTPSを利用するためには、ウェブサーバに「サーバ証明書」を配置する必要があります。これは、シマンテック社などの第三者機関が「このサーバは間違いなくこの会社で運用されているサーバですよ」というお墨付きを与えるものです。 ひとつ注意しないといけないのは、なりすましサイトもサーバ証明書を導入してHTTPS化している可能性があるということです。ブラウザから証明書を表示し、ちゃんと第三者期間のお墨付きを得た信頼できる証明書なのか確認することも重要です。   SEOに有利になる 検索エンジンがウェブサイトを検索結果に表示する際、検索エンジンによってはHTTPS化されているウェブサイトを検索結果の上位になるようにしていることがあります。GoogleはHTTPS化したサイトを優遇して検索結果に表示すると公に発表しています。 GoogleのHTTPS化への圧力は結構強いものがあり、最新のGoogle ChromeではHTTPS化していないサイトを閲覧すると警告が表示されます。URL入力欄の隣に「！ 保護されていない通信」と表示されているサイトは、HTTPで通信していることを示しています。   暗号化プロトコルの違い HTTPSでは通信を暗号化する技術が使われますが、この暗号化技術（暗号化プロトコル）にはいくつか種類があります。「安全性が低いので使ってはいけませんよ」とアナウンスされている物もありますので、こちらでご紹介します。   SSLとは SSLは、一昔前に使われていた暗号化プロトコルです。SSL1.0〜SSL3.0までバージョンがありますが、2020年現在ではすべてのバージョンで脆弱性が指摘されておりますので、使用しないことが望ましいです。   TLSとは TLSはSSLの次期バージョンとして広まっている物ですが、このTLSについては2020年現在、TLS1.0〜TLS1.3まで存在します。このうち、TLS1.0, 1.1については脆弱性が指摘されており、使用しないことが望ましいです。 新規にウェブサイトを構築する場合は、暗号プロトコルとしてTLS1.2もしくは1.3を選択したほうが良いでしょう。   通信プロトコルの選択手段 SSL/TLSのうちどの通信プロトコルを使うかは、クライアント（ウェブブラウザ）の設定と、ウェブサーバ側の設定で決まります。 クライアント、サーバいずれも、「この暗号化プロトコルは使ってもいいですよ」と許可する形で設定を行います。どちらか一方で拒否しているプロトコルは使えないため、クライアント側が許可しているプロトコルをサーバ側がすべて拒否している場合はサイトを閲覧することができません。 InternetExplorerの古いバージョンではSSLしか使えないものもありますので、こうした古いブラウザで閲覧できるサイトはどんどん減っていることと思います。   必要の無いケース 顧客にウェブサービスを提供する上ではHTTPS化は必須と言えると思いますが、何でもかんでもHTTPSにしなければならないというわけではなく、HTTPSには以下のようなデメリットもあります。   費用がかかる HTTPSを実現するにはサーバ証明書が必要ですが、このサーバ証明書は数年単位の更新で、年額数万円が必要になることもあります。 ただ、最近はLet’s Encryptというサービスもあり、これを利用すると無料でサーバ証明書を導入することも可能です。   リソース消費が増える HTTPでの通信と比較して、HTTPSは暗号化の処理が走りますので、その分サーバのリソース消費が大きくなります。   こうしたデメリットを踏まえた上で、HTTPSを利用する必要が無いのは以下のようなケースです。   開発環境 […]

ユーザーの声をより反映できるサービス提供

現代では様々なサービス、商品があらゆるユーザーの手にわたり、人々の生活を豊かにするものとなっています。サービス提供の流れ、というものはある程度確実な形が存在していますが、中には少し違う方式があります。   今回紹介する方式のサービス提供を実際に活用している事業についても紹介していきます。 目次： 従来とは違う流れ オンラインクラスサービス【CLASS 101】 旅行企画SNS【Trippiece】 クラウドファンディング-ロモグラフィ社によるフィルム製造の例 クラウドファンディング-美術館KAMUの例 このような提供方式を採用することで得られるメリット まとめ 従来とは違う流れ 提供されている多くのサービスでは、上の画像のような流れが適用されています。まず初めにサービスの提供を行い、それに対してのリアクションを受け取って改良を繰り返していきます。   最大の特徴、上で紹介したものとの違いはサービスの提供の前にユーザーからの声を取り入れている、という点でしょう。   反面ユーザーの需要が一定数無ければコンテンツの提供までつながりづらいという点もありますが、実際にこれを採用している例も多くみられます。次は、その具体例を業界別にいくつか紹介していきます。   オンラインクラスサービス【CLASS 101】 CLASS 101は、韓国とアメリカを拠点に置くサービス。2020年の2月からは日本でもサービスを展開し始めました。   サービスの流れ ①クラスの掲載 イラストや写真、料理やハンドメイドなど多くのジャンルに関するクラスを掲載します。掲載ページには習得難易度や詳細が載せられており、予め確認が可能です。   ②希望者の募集 HPには多くのクラスが掲載されていますが、その全てが開講出来る、というわけではありません。クラスの開講のためには、希望者の応募が100人集まる必要があります。その時点で何人が応募しているかは常にメーターで確認することが出来、クラスの掲載主、ユーザーの双方にとってわかりやすい機能となっています。   ③開講 100人を超えると実際にクラスが開講されます。受講の際に使用する材料は予めCLASS 101から予め配送され、授業動画は期間内であれば何回でも視聴することが出来るため、確実に知識と技術の定着が可能です。他の受講生との共有、提出した作品に対してのフィードバックもあり、ユーザーにとって優しいコンテンツを提供していることがわかります。   冒頭で紹介したサービス提供の流れを活用してサービスを提供していることが分かったかと思いますが、そのなかでもCLASS 101の大きな魅力と言えるのはコンテンツ提供後の充実さではないでしょうか。   100人の応募者という条件を満たしたクラスだけを開講することで大多数のユーザーの需要を満たせるようにしていますが、受講生が求める「自分の技術の上達」を実現できるように更にサービスを提供しているという点は、CLASS 101の武器といえるでしょう。視点を変えて考えれば、最初に挙げた従来の流れにある「ユーザーの要望、意見に合わせたコンテンツのアップデート」という箇所をうまく変形させて組み込んでいる、とも言えそうですね。   旅行企画SNS【Trippiece】 株式会社Trippieceが旅行メディア「RETRIP」と一緒に2011年から運営しているサービス。2013年には観光庁長官賞も受賞しており、十分に知名度を得ています。   サービスの流れ ①企画の掲載 Trippieceが認可した企画プランナーによる旅行案を掲載しています。プランナー個人が立案を行うため、旅行会社の企画するプランよりも珍しい場所、内容のものが多くなっています。   ②参加者の募集 掲載から一定の期間、参加者を募る期間が設けられます。他のユーザーがどの程度企画に興味をもっているかがわかる投票機能なども提供されている為に応募期間の途中でもある程度需要を把握することが出来るように設計されていますが、旅行というコンテンツの特性上どうしても参加者を目標まで募れずに企画倒れしてしまうケースも多いようです。   ③ツアーの具体的な内容を練る 参加者とプランナーの間で、ツアーの中身を練っていきます。旅行先で自分がしてみたいことを組み込みやすいという利点があり、より満足するコンテンツに仕上げることが出来ます。   ④出発 […]

オプスインでの要件定義の進め方-CtoCマッチングシステムを例に

新規事業を構想して、システムの開発を進めようと思った時、 まず最初に要件定義を行います。 本記事では、オプスインでの要件定義の進め方を、 架空の中古家具CtoCマッチングシステムでの要件定義を例に説明いたします。 (※進め方はあくまで一例です。プロジェクトの規模や内容によって変わることがございます。）   1. サービスに関係する人の種類とサービスで行われることのヒアリング まずは、このサービスでどのようなことが行われるかをヒアリングしていきます。 「家具を出品し」と一言にいっても、それを実現するためには、そもそも「家具が登録」されていないといけませんし、 家具を登録する前には、「ユーザーアカウント登録」や「ログイン」をしている必要があります。 サービスを成り立たせるために必要なすべてのプロセスをヒアリングし、可視化してきます。   同時に、どんな関係者(=アクター)がいてどんなことを行うかをヒアリングします。 概要から、出品と購入をするユーザー、運営管理者が必要なことはわかりますが、 他にも購入された家具を輸送することに関連するアクターや、 もしかしたら、出品された家具を保管する倉庫に関連するアクターもいるかもしれません。 関係者の洗い出しと関係者ごとのプロセスを可視化していくことで、 サービスで行われることを明確にします。   2. 機能一覧と画面一覧の定義 サービスで行われることが明確になったら次は、 それを実現する上で必要なシステムの機能を定義していきます。     例えば、「ユーザーが購入する家具を探す」といったプロセスがあった場合にも、 家具の種類や条件から探す、部屋のテイストから探す、評価の高い出品者から探すなどいろんな形態が考えられます。 サービス特性に応じてどんな機能が必要かということをヒアリングしながら、定義していきます。 機能の定義が終わったら次は、 それらの機能を実現する上で必要な画面を定義します。 例えば「ユーザーが会員登録をする」機能を実現するためには、 「メールアドレスとパスワードを登録する」画面 「認証メールを送信完了したことを表示する」画面 「初回ログイン時プロフィールを入力する」画面 などが必要になるかもしれません。 実際のユーザーの操作を想像しながら画面を定義します。   3. 外部システムとの関係や連携機能の定義 本システム内では行わず、外部のシステムで行うことも定義していきます。   例えば、 購入時のクレジットカード決済機能はStripe(決済代行サービス)を利用する、 ユーザーからの問い合わせ対応はZendesk(カスタマーソフトウェア)を利用するなど、 利用する外部システムの定義と、連携方法の定義を行います   4. 定時で自動実行される(バッチ)機能の定義 画面には表れないような、定時で自動実行される(バッチ)機能も漏れなく定義をしていきます。 例えば、 購入してxx日後の9:00に家具使用感のレビュー依頼をメールで通知する などサービスを成り立たせるために必要な機能を定義します。   5. […]

EAフレームワークに基づく要件定義の実践

はじめに こんにちは、オプスイン開発部の乾です。私は現在システム開発プロジェクトの要件定義を担当しています。 早速ですが本記事の結論から申しますと、要件定義で成果物を体系的に作成することで、EAを実践しつつ顧客から信頼いただけるシステム開発を実現していきたい、と考えています。 要件定義とは システム開発における要件定義とは、何を作るかを決める工程です。要件定義が終了すれば、（理想的には）あとは要件定義書にしたがってシステムを作るだけです。よって、要件定義で重要なのは、どんなシステムを作るかについて、顧客と合意することです。 具体的には何をもとに合意すれば良いのでしょうか？IPAの資料室には、機能要件の合意形成ガイドとして下記が上がっています。 システム振る舞い設計 画面設計 データモデル設計 外部インタフェース設計 バッチ設計 帳票設計 オプスインではこれらの要件定義フェーズの成果物として特に下記の項目を重要視し、テンプレート化しています。 業務フロー図 機能リスト 画面リスト 外部インタフェースリスト バッチリスト インフラ構成図 非機能要件リスト EA 一方、EA（エンタープライズアーキテクチャ）という言葉をご存知でしょうか？ サイト https://www.cloudtimes.jp/dynamics365/blog/enterprise-architecture.html から引用すると、 EAとは経営戦略とITを絡めた全体最適化によって、顧客ニーズをはじめとする社会環境や情報技術自体の変化に素早く対応するための構造です。EAを実践することで企業は組織全体で統一された情報、効率良く整備された業務プロセスを手に入れることができ、利益率をアップしたり、新たなビジネス価値を創出することができます。 となります。参考までにEAは４つのアーキテクチャからなります。 BA（ビジネスアーキテクチャ ） AA（アプリケーションアーキテクチャ ） DA（データアーキテクチャ ） TA（テクノロジーアーキテクチャ ） 概念的にはわかったような分からないような、実現できたら良いとは思いますが、実際にどうしたら良いかが分からないですよね。再びIPAの資料室に戻りますが、EAフレームワークがあります。ここではEAの各アーキテクチャをEAプロセスと主要成果物として下記のように定義されています。 BA BA-1 （ファンクション/プロセス分析） DFD BA-2（情報分析） 情報リスト BA-3（業務フロー作成） 業務フロー AA AA-1（システム機能定義） システム機能階層図 システム機能定義書 AA-2（システム関連定義） システム関連図 システム間インタフェース定義書 DA DA-1（概念データモデル作成） 概念ERD DA-2（論理データモデル作成） 論理ERD […]

Webシステム開発におけるテスト工程での不具合検出と安全性の検証について

Webシステム開発におけるテスト工程での不具合検出と安全性の検証について   Webシステムの開発においてテスト工程では画面（ブラウザ）からの操作による正常系・異常系の動作が要件に合っているかというテストは勿論ですが ツールを使用する事で様々な視点からのセキュリティ、盤石性の検証を行っております。 この記事では検証に使用しているツールを一部ご紹介すると共に そのツールを使用する事により何を検証し、何を防げるのかという内容を掲載しております。 （各ツール共に多様な機能を擁しており目的に応じて様々な使い方がありますが、本記事ではテストの目的に沿った使い方の一例をご紹介しております。）   目次： セキュリティテスト 負荷テスト 権限テスト   1. セキュリティテスト   使用ツール：OWASP ZAP, brakeman(Ruby-Railsプロジェクト) 参考サイト： https://www.zaproxy.org/ (OWASP ZAP公式サイト) https://github.com/presidentbeef/brakeman (brakeman)     OWASP ZAPについて テスト内容： 画面（ブラウザ）からの操作を記録し実際の操作を想定したシステムの脆弱性を検出 検出できる脆弱性の一例   クロスサイトスクリプティング 悪意のあるユーザーが不正なスクリプトをデータとして登録することで、 別のユーザーがそのデータを取得する際に悪意のあるスクリプトがブラウザで実行されてしまう脆弱性   SQLインジェクション サーバーへの問い合わせ情報にSQL（データベースへの問い合わせ言語）文を混入させることで サーバー上でSQLが実行され意図せぬデータの改ざん、搾取等が行われる攻撃手段 その他にも様々なシステムの脆弱性に対し自動検出を行ってくれます。 詳しくは以下公式サイト（英語）に掲載されています。 https://www.zaproxy.org/docs/desktop/addons/active-scan-rules/     Brakemanについて テスト内容： ソースコードの静的分析ツール（Ruby on Railsのプロジェクトに限る）   Ruby on Railsで開発されたプログラムのソースコードを 自動で分析、検証、セキュリティの脆弱性を検出 […]

既存システムのテスト自動化を考える

既存システムのテスト自動化を考える   目次: はじめに テスト自動化のメリット テスト自動化のスコープ 既存システムのテストを自動化する おわりに はじめに 皆さんこんにちは！オプスイン開発エンジニアの新川です。 最近、他社さんより引き継いだシステムを継続開発する中で、品質を担保するためにテスト自動化への取り組みを進めています。 本記事では、テスト自動化とは何なのか、何のために、どのような方法で行うのか、さらに、既存機能のテストを自動化する上でどのように行うか、検討した内容などをご紹介したいと思います。   テスト自動化とは？ Wikipediaでは、以下のように記載されています。   テスト自動化（テストじどうか）とは、テスト支援ツール等を使うことにより、ソフトウェアテストを自動化することである。   「テスト支援ツール」って何？と思う方もいらっしゃるかもしれません。 テスト支援ツールはテスト対象やスコープに応じて様々にカテゴライズされると思いますが、皆様に身近なもので言うと、最近のWeb開発フレームワークには大抵このテストツールが標準で備わっているか、あるいはパッケージ追加で利用可能にできるケースが多いと思います。 弊社ではRuby on Railsで開発を行う場面が多いですが、Railsのチュートリアル本家でも標準搭載のMinitestを用いたテスト方法が紹介されています。こうしたWebフレームワーク用のテストを実行する際は、コマンドライン上でテスト用のコマンドを実行するだけで、自動でテスト用データベースを自動作成し、テストが行われ、結果が得られます。Minitestでもそうですが、テストツールを用いてテストを自動化する場合、ソースコードとは別にテストコードを別途作成し、同じプロジェクト内にコミットするのが基本です。これにより、開発者が開発後に手軽にテストを走らせることができます。   テスト自動化のメリット 「テストコードを別途書くのって、開発工数上がるんじゃない？」と思う方もいらっしゃるかもしれませんが、その通りだと思います。しかも、フレームワークの実装方法が分かっていればすぐテストが書けるというものでもなく、テストコードはテストコード専用の知識が必要だったりして、学習コストも上がります。 ただ、私はテスト自動化を進めることで、結果的に多くの場面で開発コストダウンと品質アップに繋がるんじゃないかと考えています。 この辺りは散々、他の記事でも紹介されていることですが、以下のようなものが個人的に思う主なメリットです。 テスト工数の削減になる 自動でテストした部分は品質が担保されているので、テスターが改めて手動でテストを行う必要がありません。開発時点でテストを何度も回すわけなので、実装完了時点での品質も上がり、テスト後の修正工数も下がるはずです。 ただ個人的には、新規に開発した部分に限り、自動テスト任せにするのではなく、全ての機能についてテスターによるテスト（目視の確認）も必要だと思います。 開発後のデグレに気付ける 「全然関係ない機能を開発していたところ、意図しない形で既存機能に不具合をもたらしてしまった」と言う経験、皆さんお持ちだと思います。 テスト自動化は毎回全てのテストを回すのが基本ですので、構築時点でテストを書いておけば、意図した通りに動作しなくなった時点ですぐに気づくことができます。 このため、開発段階で不具合に気づくことができ、修正をかけられます。また、テスターが追加開発ごとに全ての既存機能について詳細に動作をテストする必要がなくなります。 テストコードが仕様書になる 個人的には意外と重要な効果だと思うんですが、整理整頓して記載されたテストコードがあれば、読むだけで「そのシステムにどんな機能があるのか」が詳細に把握できます。 このため、詳細なドキュメントがなくても、引き継いだ人がテストコードを読むだけでシステムの中身を十分把握できるという効果ももたらされるように思います。 「仕様書？なにそれおいしいの？」という状態のプロジェクトも世の中にはたくさんあると思いますが、テストコードをしっかり書くことで、引き継がれた人にも優しいシステムになるのではないでしょうか。 テスト自動化のスコープ これは個人的な主観も入りますが、ウェブシステムを例にとると、テスト自動化のスコープは大きく二つあると思います。 サーバサイドのテスト自動化 RailsのMinitestなど、バックエンドフレームワークのテストツールで自動化する範囲がここに当たります。 サーバサイドのため、モデルのバリデーション、POSTデータの受け渡しなどがメインのテストスコープになるかと思います。フロントエンド側でReactなど別のフレームワークを用いている場合などは、フロントエンド側はスコープ外となります。 利点として、フレームワーク側の言語を使ってテストコードを記述できるので、新たに言語を学習する必要がありません。また、ORMによるデータ操作もそのまま利用できますので、モデルに実装したカスタムメソッドなどもそのまま利用できます。また、テスト用のデータベースの作成や、テスト後のクリーンアップを自動でやってくれる機能が、テストツールに大抵備わっていますので、そうした機能を有効活用できます。 エンドツーエンドのテスト自動化 クライアント操作を自動化して行うテストです。ブラウザであれば、Puppeteer、Seleniumなどが利用されます。 フロントエンドも含めた一気通貫のテストですので、実際のユーザの操作と同じ環境でテストを行うことができます。 利点としては、ユーザの操作をほぼ完全に再現できるので、「フロントエンド側のUIコンポーネントが表示されていない」といった不具合にも気づくことができます。また、とりあえずエンドツーエンドでテストが通ったケースについてはサーバサイド側もOKと考えることもできるので、一石二鳥です。さらに、テスト自体は極端な話別プロジェクトにしてもいいくらいに疎結合にできるので、既存のシステムに影響を与えません。 難点として、クライアント操作自動化のための別言語を学習するコストがかかることや、データベースの生成やクリーンアップは手動で行わなくてはならないことなどが挙げられます。 既存システムのテストを自動化する 他社さん、もしくは社内の別担当者から開発を引き継ぐような経験、みなさんお持ちだと思います。 引き継がれた時点でテストがしっかり実装され運用が確立されている場合は万々歳ですが、私はこれまでそんな経験は一度としてありません。（泣） こうしたシステムを継続的に開発していくにあたり、後追いでテスト自動化を実現する方法について検討しました。 結論から言うと、小規模なシステムであれば、クライアント自動化を用いたエンドツーエンドのスコープで自動化する方が良いと思います。 […]

CakePHPでWebAPIを開発した時にハマったこと

あるプロジェクトでオンプレミス環境（自社運用型）に広報関係のWebサイトを構築する案件を担当しました。 主に広報に関わる内容でしたので、更新系の処理はほとんど無く、参照／表示がメインコンテンツとなるサイトです。 目次： WebAPI開発 試したこと．その１：インデックスを張りなおす 試したこと．その２：OPCacheを有効化する 疑惑と調査 試したこと．その３：フレームワークを切り替える 終わりに WebAPI開発 フロント（デザイン）をVue.jsで構築し、バックエンドはphp5.6で構成するSPAサイトで、オンプレミス環境のためサーバスペックも固定の基盤をターゲットにした開発案件でした。 このプロジェクトでは当初、phpではメジャーなフレームワークであるCakePHPを採用して開発していました。 一旦は滞りなく開発が完了したところで、本番環境と同等のコンテンツ量で最終確認を実施したところ、CakePHPで構築したAPIのレスポンスが著しく遅いことが判明し、とてもではないけれど本番にリリースができる代物ではありませんでした。 ここから速度改善に向けての試行錯誤が始まりました。 試したこと．その１：インデックスを張りなおす もともとインデックスの設定はしてあったのですが、後から仕様変更によって検索条件が変更されたケースがあったので、インデックスを張りなおしてみました。 しかし、この対応には目に見えた効果は無く、一部検索条件の際に生じていた更なる速度低下を抑え込む程度の改善効果しかありませんでした。 試したこと．その２：OPCacheを有効化する phpはインタプリタ型のスクリプト言語で、コンパイル不要の手軽さが売りですが、その分速度を犠牲にしている面があります。 OPCacheとはphpコードをコンパイルし、コンパイルされたコードをメモリにキャッシュすることで高速化を図る仕組みです。 このOPCacheの導入により、およそ２倍の速度改善を実現することができました。が、しかし、それでもまだサイトを表示するときの体感速度は遅く、まだまだ本番にリリースできる状態とは言えませんでした。 疑惑と調査 確かにコンテンツ量は多く、また、デザイン要件のため一度に取得するデータ量を抑え込むことが難しかったとはいえ、キャッシュしても実用に耐えられない速度に疑問を抱きました。 そこで、おもむろに開発環境で動作中のWebサイトに向けてF5連打をしてみたところ、あっという間にCPU使用率が最大値に張り付いてしまうことが判明したのです。 負荷試験ツールであるJMeterで計測している時にCPU使用率が最大値で張り付いていることは認識していましたが、一人のアクセスユーザーがF5を連打しただけで開発機がパンクしてしまうのは尋常では無いと考え、諸々調査したところ、php5.x系とCakePHPの組み合わせではCPU負荷が高くなりやすく、php7から改善されたという情報を目の当たりにしたのです。 https://www.php.net/archive/2015.php#id2015-12-03-1 ※公式リリースにも2倍速くなったという記載が。 ・Improved performance: PHP 7 is up to twice as fast as PHP 5.6 試したこと．その３：フレームワークを切り替える この時のプロジェクトではハードウェアもミドルウェアも全てが指定されていたため、phpのバージョンを上げるという対策を取ることはできませんでした。 そこで、技術選定できるフレームワークを見直すことを考え、CakePHPよりも高速なフレームワークが無いか調べたところ、Phalconに辿り着いたのです。 https://phalcon.io/ja-jp ロジックのコア部分は完成していたので、CakePHPからPhalconに載せ替えを行うイメージの開発でしたが、これにはそれほど時間はかかりませんでした。 結果として、スループットで比較すると初期のOPCache無しと比べておよそ16倍、OPCacheありと比べてもだいたい8倍近い速度改善を達成することができたのです。 もちろん、Webサイトを表示する体感速度も見違えるほど良くなり、F5を連打をしてもCPU使用率は20%前後で頭打ちとなる改善を果たすことができました。 終わりに CakePHPにもREST-API開発を目的とした仕組みはあります。(ルーティングの設定であったり、jsonを返却したり) 真っ先に飛びついたのですが、この時はあまり改善を見ることができませんでした。 恐らくDBのO/Rマッピングがボトルネックになっていたのではないかと推測しています。 昨今のWeb開発においてはフレームワークの利用は当たり前で、工数的にもセキュリティ的にも、これを用いずにゼロから開発するということは考えられません。 ですが、フレームワークにも得手不得手があるのも事実です。 いまや切っても切り離せない重要な役割を担うフレームワークだからこそ、システム要件と十分につき合わせた選定が大事になるかと思います。

テストを素早く正確に実施するための取り組み

テストフェーズは、システムの品質を担保する上で重要な工程です。 実装された各機能、各画面に対して、環境別(ブラウザや端末)のテストが必要であり、 大量のテスト項目に対して、素早く正確なテスト実施が求められます。 全体の開発期間を短くするために、 上記を実現するために、 オプスインでは、常にテスターを採用し、そのテスターに対して試験を行なっております。 その取り組みについてご紹介します。   1. テスターメンバーを常時募集しています 採用媒体や知人の紹介等、テスターメンバーを常に募集しています。 在宅ワークでの勤務で働きやすいこともあり、 月に50名程度応募いただいております。(2020年5月現在) 2. テスターメンバーに対するテストを行なっています 採用プロセスの中で、擬似プロジェクトに対するテストを実施いただいています。 テスト設計書に対して実施にテストを行っていただき、含まれている不具合を正しく報告できるかを確認しております。 テスト設計書に直接記載されていない部分でUXの違和感に気づけるかもチェック項目に盛り込まれており、通過率は5%程となっております。(2020年5月現在) 3. テスト方法やTipsを共有しています 採用後も、「OWASP ZAPを利用したセキュリティ脆弱性診断実施方法」などテスト業務に必要な知識、マニュアルや、 オプスインのテスト業務で蓄積したテスト時のTipsを共有することで、 テストの精度向上に努めております。 上記のような取り組みのおかげで、 オプスインでは複数のメンバーで一気に、素早く正確なテストを行うことができます。 今後も、品質の高いシステムを短い期間で開発するために工夫を凝らしています。

オプスインのセキュリティ対策の取り組み

2019年に世間を驚かせたセキュリティ事件といえば、利用者に金銭被害が生じるなど多大なインパクトがあった「7pay」の不正アクセスではないでしょうか。 それ以外にも、「クロネコメンバーズ」の不正ログインや、ゆうちょ銀行を騙ったフィッシング詐欺など、2019年も世間を騒がしたセキュリティ事故が相次ぎました。 JNSAの調査分析で2018年の調査報告書を見ますと、セキュリティ事故の件数としては「紛失・置忘れ」や「誤操作」が多く、次いで「不正アクセス」「管理ミス」と続き、割合としてはセキュリティ事故の75%を占めています。 一方でWebサイトの改竄や乗っ取り等のセキュリティホールに起因する被害は、前述のケースと比較して少ない件数となっていました。 ■引用：JNSA セキュリティ被害調査ワーキンググループによる個人情報漏えい事件・事故の調査分析（2018年） これはWebシステムの開発で利用しているフレームワークの進化や、開発の現場でセキュリティ対策の取り組みが進んでいるからといえるでしょう。 つまり、Webシステム開発においては正しくセキュアに取り組むことで、不用意なセキュリティ事故を避けることができるということです。 本記事でオプスインではどのようなセキュリティ対策に取り組んでいるのかを紹介したいと思います。 目次：   Webシステム開発での取り組み 基盤のセキュリティ対策 まとめ 1.Webシステム開発での取り組み オプスインの手掛けるWebシステムではRuby on Railsベースのシステムが多いのですが、Rubyのgemライブラリには「brakeman」というセキュリティに重点を置いたRailsプロジェクトの静的解析ツールがあります。 これはソースコード上にSQLインジェクションやXSS等の脆弱性と疑わしき箇所がある場合に検知してくれるツールで、例えばURLパラメータを検証せずにそのままプログラム内で利用しようとすると「Security Warnings」として該当箇所のコードが分かる仕組みになっています。 この「brakeman」を利用することによって、システム開発時のコーディング段階で作り込んでしまった脆弱性を洗い出すことが可能となり、セキュアなシステム開発に取り組むことができています。   ■参考：https://github.com/presidentbeef/brakeman   また、開発完了時には「OWASP ZAP」を用いたセキュリティテストを実施しています。 この「OWASP ZAP」はWebシステムのセキュリティに関するガイドやツールを公開している「OWASP (The Open Web Application Security Project)」が開発しているオープンソースのWebシステム脆弱性診断ツールです。「OWASP ZAP」には様々な使用方法がありますが、そのうちの一つとして実際にブラウザを操作して対象のWebシステムの使用方法を記録し、データの入出力なども再現しながら各機能ごとに脆弱性診断を行う機能があり、CSRF対策しているWebシステムでも大部分の機能を網羅することができ、とても重宝しています。   ■参考：OWASP Zed Attack Proxy Project   Webシステム開発時の取り組みとして活用している「brakeman」や「OWASP ZAP」ですが、これらは機械的に検知するため、どうしても誤検知の可能性が付いて回ります。 何に対してアラートが上がっているのか、最終的にはしっかりと人間の目で確認することで、出来る限り脆弱性を作り込まないシステム開発が可能になるように取り組んでいます。 2.基盤のセキュリティ対策 セキュリティ対策において、セキュアなコーディングを車輪の片輪とするならば、もう片方はセキュアなインフラの構築にあると考えています。オプスインでは主にクラウドサービスを利用しているため、基盤のセキュリティには十二分に留意しています。 まず、サーバーにアクセスできるユーザーを限定するため、原則として公開鍵認証を必須としたサーバー運用を行っています。 そして、特にセンシティブな情報を取り扱う本番サーバーへのアクセスにおいては、接続元のIPアドレスも限定することで、不用意に第三者がサーバーへアクセスすること自体をできないように対策を行っています。 アクセスできるユーザー、環境を制限することで、悪意のある攻撃者にサーバーそのものが晒されないように対策しているのです。 また、WAF（Web Application Firewall）やIDS（Intrusion Detection System）、IPS（Intrusion […]

発注前に知っておきたい！システム開発の流れと注意点

インターネットの発達に伴い、デジタル化が進む昨今では、事業を推進するためのシステム開発が必須となりつつあります。技術者が必要となるシステム開発にハードルを感じる人も多いのではないでしょうか。システムを自社開発できない企業は、開発会社に外注する方法が最適です。開発会社では効率的にシステム開発を行えるため、開発にかかる余計な時間や費用を減らせます。 システム開発を外注するには事前に開発の流れを知っておき、発注する際の注意点を知っておくことが重要です。当記事では、依頼から開発までの流れやキーポイントについて解説していきます。 目次： 依頼から開発までの基本的な流れ 発注側も基礎知識を持ち、協力する姿勢が大切 誤解しやすい保守と運用の違いは？ 無駄な追加請求を抑える見積もりとは？ 契約書を締結する際のポイントとは？ 開発会社に丸投げしない姿勢が大切 依頼から開発までの基本的な流れ 開発会社にシステム開発を外注する場合、基本的には以下の流れに従って開発が進みます。システムの規模や特性によって違う場合もありますので、あくまでも基本の流れをご紹介します。 打ち合わせをして、システム開発会社が提案書を作成   ↓   提案を確認して発注     ↓   システムの詳細仕様を決める     ↓   仕様を確認してから開発     ↓   完成したシステムの検証     ↓   システムの公開     開発会社でシステムを開発する場合、最初に開発するシステムに求める機能を決めるために打ち合わせをします。必要な機能やアイデア、予算の上限を初回の打ち合わせで決めることもあります。発注側の要望をヒアリングした開発会社は後日、提案書や見積書を提示して確認を取ります。提案書にはシステム導入によるメリットが記載されていて、システム開発の必要性を考慮するときに役立ちます。開発会社の提案に同意をしたら、次にシステムについて打ち合わせを行います。開発するシステムを具体的に決めて、設計書が完成するまで綿密にコミュニケーションを取りましょう。 打ち合わせでシステムの仕様がすべて決まったら、開発会社から仕様が提示されます。仕様は開発した後に変えることは難しいので、問題がないかシステムの設計をよく確認しましょう。仕様に問題がなければ開発会社にて実際にシステム開発を行います。開発が終わったら発注側とシステムの検証を行い、動作する機能や必要な条件を満たしているか発注側が確認をします。条件を満たしたシステムが無事完成したら、開発会社にてシステムを公開します。 発注側も基礎知識を持ち、協力する姿勢が大切 専門的な知識を持っていない人がシステム開発を外注することもあり、中には開発会社に丸投げしてしまう方もいます。しかし、システム開発を成功させるためには、発注者側が基礎的な知識を備えておくことや、事業を成功させるためにしっかりと協力体制を整えていくことが重要なポイントです。   発注側が仕事を丸投げする問題点   システムの開発を担当する開発会社は、発注側と比べると業界への知見を深く保有していないことがあります。発注する企業では常識だと認識していることでも、開発会社にとっても常識であるとは限りません。企業で行っている事業を誰よりも知っているのは発注する担当者であり、担当者が積極的にシステム開発へ参加することが必要です。より良いシステムの開発には協調性が求められます。 家族で住む家を建てるときに、建築会社と細かいところまで仕様を決めるのと同じことです。家が完成するまで何度も確認をして、初めて希望に合ったお家に住めるようになります。公開したら何年もシステムを使っていくのですから、システム開発においても同じことです。開発会社にすべて任せるのではなく、発注側も積極的にシステム開発に参加しましょう。 誤解しやすい保守と運用の違いは？ 開発したシステムを事業に導入していくには、技術者が保守や運用をする必要があります。システムの管理には費用がかかるため、制作会社に依頼する前に保守や運用を詳しく理解しておきましょう。   システムを修正するのが保守   事業でシステムを利用していると、機能に不具合が発生したりセキュリティ性能が落ちたりします。システムにおける問題点を直すためにITエンジニアが行うことを保守と呼びます。不具合が発生したら原因を究明して、問題のある箇所を修正して改善作業をします。顧客情報などを保存するデータベースや企業のサーバーをメンテナンスするのも保守です。新しい機能をシステムに追加するのも保守と呼ぶケースもありますが、一般的には追加開発として、保守とは区別されます。発注の際は保守の範囲を確認しましょう。   システムの稼働を確認するのが運用 […]